5 ms·
I'm not sure what the takeaway from this is. Don't implement crypto in software, only hardware? Does that cut out algorithm-writers who won't have FPGAs and fa
by scott_karana 12y ago
I'm not sure what the takeaway from this is.
Don't implement crypto in software, only hardware? Does that cut out algorithm-writers who won't have FPGAs and fabrication available to them?...
- saidajigumi 12y agoOr perhaps that we need a ISA extension that provides primitives for security-sensitive code. The instructions may be superficially similar to ones we have now, but the guarantees are around properties that enable developers to reason about the security aspects of that code. /quite possibly wishful
- superuser2 12y agoAnecdotally, this is the U.S. government's infosec philosophy. Software crypto is looked down on as a toy. "Real" security applications use hardware crypto (smart cards, HSMs, other ASIC-based crypto). The civilian world might need to catch up.
- dyladan 12y agoThe takeaway is that it is extremely difficult to implement constant time calculations. It might be extended to mean that in order to have constant time crypto, you need to have a set of instructions specifically designed to be constant and predictable time.
- sliverstorm 12y agoYou don't have to have FPGA or ASIC capabilities to develop a great new algorithm, do you? Do your research, prove it in software, get it into a product later... right?
- scott_karana 12y agoTrue! My takeaway was needlessly bleak. Thanks :)
- CHY872 12y agoI don't think it would - what you implement might have more side channel attacks in, but if it's more of a PoC it shouldn't matter. On the other hand, even if it did, FPGAs are quite cheap ($100-ish for a suitable one) and if you're a serious cryptographer you're almost certainly going to be based at a university or an agency of some kind which will be able to afford one (or have a whole bunch lying around).