We cannot do anything but add cores as we have hit the "powerwall". If you want to double the speed, you need to double the power, if you have silicon. I can take the same masks and put it down on sapphire that will increase the speed by 2x, decrease the power by 2x, and increase the cost by 10x. This is why you just throw custom instructions (silicon) at everything. Also, there are user programmable FPGAs that act as coprocessors. Virtex from Xilinx.
They were in the PowerPC days as I used to use them to make custom instructions. Of course, you could just take a processor and make a "bus plugin" or sorts.
Xilinx has changed a lot since they started those 20 years ago. My MS work was funded by Xilinx and I made a hazard free CPU that was basically a coprocessor for the PowerPC.
I will say my information is outdated at this point.
x86 are a RISC core with a CISC wrapper. They just suck across the board. Everything about them is terrible form the semiconductor perspective. :(
SPARC v7 had coprocessor instructions that anyone could use. No one made coprocessors at the time. This is why LEON is very popular in the dev world as if you need a coprocessor, you can just target a SPARCv7.
Like any other company, once you get big you stop understanding your product. It's "units" now and not specific products. They've been buying up anyone that has an value now that silicon has screeched to a halt. Andy was a chemist, and could run a company. The more recent CEOs have been b-school people.
I guess this is not vulnerable to:
padding oracle attack because it is basically counter mode
stream cipher attack, because it isn't just simply XOR-d
malleability, because XOR-ing something on the ciphertext changes the entire plaintext
A significant disadvantage is that it needs a new key...
@forest @SEJPM @bdegnan The problem I see with modifiable CPU architectures is that now the OS configures the CPU. I'm not sure if you want to change the CPU configuration per application. And you need the specialization per application more than for the OS, I presume.
@kelalaka Although I agree with SEJPM, I'd rather see that kind of question on superuser. Currently we have to rely on the description of the user of LUKS to say he's right or wrong. I'm not sure if there are any LUKS specialists; I'm definitely not going to answer that one.
The practical problems with reconfigurable hardware on the CPU would be handing what happens when you have an interrupt or a trap. This is most likely why you would just make a dedicated processor with custom instructions. You could always do the "old style" of throwing a trap and passing it off to the bus. I've been trying to come up with a good application for this. The only thing I have is homomorphic encryption or actually having circuits for Yao's circuits.
I have full masks for both sync and async FPGAs on GF14nm. I guess I could write a grant.
That's cool enough, although I do think that FPGA's could also be used for things like block ciphers. That would make them less specific for e.g. AES. How fast can you reconfigure them? Could you configure them using SRAM or similarly fast and non-persistent?
No the mode would not be more secure (than what?).
I guess this is not vulnerable to:
padding oracle attack because it is basically counter mode
That's not correct. As the input of a block cipher is always a full block, you would need to pad the plaintext. Therefore you would lik...
I need to just sit down with some cryptographers and sort out some cool hardware/crypto collaboration. There's some neat problems, but I just don't know where they are. Mostly, I know nothing about cryptography, and I'm mostly interested in just not making bad semiconductor implementations.
If you go down that way, yes, you should probably link up with cryptographers, preferably at university level. There are some universities that are more technical and do crypto.
I've had some of my software reviewed by multiple parties. The universities were generally better than the test labs, although I do have to give some credit to Riscure at the time.
Most of the problems that I see on the semiconductor side are a function of minimizing 1) area, and 2) power. For instance, I would like to see some hash function that uses shared hardware with AES. I'm less interested in making new algorithms than making implementations that minimize current circuits.
It very much depends on the area a cryptographer works in. People in theory certainly don't care about the concrete efficiency of hardware implementations of other people's algorithms.
I don't know if there is anything cryptographers can do with other people's algorithms. If you propose a change then you have a new algorithm. Creating the most efficient least cost hardware implementation of an attack on a cipher wouldn't be something they would do either. We want are stuff to be definitely secure now and in the future, so just deliberately over estimate the power of the adversary and you have a bit extra of a security margin.
@kelalaka you clearly overestimate how specific most grants in the area are. Or you underestimate people's skill in convincingly arguing that largely unrelated papers clearly fall within some arbitrary project.
Most people learn that skill already during their PhD.
I guess this is not vulnerable to:
padding oracle attack because it is basically counter mode
stream cipher attack, because it isn't just simply XOR-d
malleability, because XOR-ing something on the ciphertext changes the entire plaintext
A significant disadvantage is that it needs a new key...
No the mode would not be more secure (than what?).
I guess this is not vulnerable to:
padding oracle attack because it is basically counter mode
That's not correct. As the input of a block cipher is always a full block, you would need to pad the plaintext. Therefore you would lik...
