4 ms·
AES-specific instructions were even a bit questionable... but this is highly questionable. Algorithm-specific instructions are basically going to become very da
by api 13y ago
AES-specific instructions were even a bit questionable... but this is highly questionable. Algorithm-specific instructions are basically going to become very dated cruft within a few years to a decade tops and are probably a bad thing to add to any instruction set. Better would be to add instructions for speeding up all sorts of crypto algorithms.
- steve19 13y agoThey can just implement cruft in microcode rather than silicon. In the meantime everyone using AES for full disk encryption gets a nice speedup.
- geofft 13y agoAES-specific instructions are also the only sane way to implement AES without timing attacks. I'm curious about this "instructions for speeding up all sorts of crypto algorithms" proposal -- how would you do that, given that crypto algorithms tend to have a wide variety of implementations and a wide variety of mathematical underpinnings? Do you want instructions that speed up all sorts of math?
- tptacek 13y agoI'm not sure that's true. Maybe you're thinking about implementing GCM without lookup tables; GCM is most often considered in AES context, and is infamously tricky to do in software in constant time and reasonable speed.
- geofft 13y agoI might have it confused? I thought there were cache-timing issues with doing lookups in the S-box in RAM, for instance. I certainly also buy that the Intel GCM acceleration functions are useful.
- tptacek 13y agoThere are definitely AES cache timing issues! I had it in my head that GHASH was harder to make constant time than AES, probably because of Adam Langley, but 'pbsd points out that it's subtler than that. Both GCM and AES are tricky to do in constant time in software.
- pbsd 13y agoHe's right; implementing plain constant-time AES can be done without AES-NI, but is by no means easy or obvious.
- tptacek 13y agoI didn't think it was obvious, but also didn't think the performance hit was as bad. (We're getting out of my comfort zone; I know how constant time AES implementations work, but not what the current speed records are for them.)
- pbsd 13y agoThe best timings I'm aware of are ~7cpb for AES-CTR, and ~14cpb for GHASH on Nehalem [2]. It's a bitsliced implementation, so it makes sense to compare it to counter-mode AES-NI. A recent AES-NI implementation on Sandy Bridge [1, pg. 25-26] achieves 0.79cpb for AES-CTR, and 1.68cpb for GHASH. The point: the ratios 14/1.68 and 7/0.79 are quite similar. PS: The performance of PCLMULQDQ was vastly improved in Haswell, and I believe AES-GCM in there runs at something like 1.5cpb. However, the vector size of Haswell also doubles to 256 bits, which would also improve an hypothetical bitsliced AES-GCM implementation. Hard to say what that speed would be, so I won't try to compare things in Haswell. [1] https://crypto.stanford.edu/RealWorldCrypto/slides/gueron.pdf https://crypto.stanford.edu/RealWorldCrypto/slides/gueron.pd... [2] http://eprint.iacr.org/2009/129 http://eprint.iacr.org/2009/129
- sillysaurus2 13y agoIf you want to use AES without exposing yourself to timing attacks, the correct course of action is to use NaCl.
- jevinskie 13y agoAES-NI instructions have their own bit in CPUID (not bundled with any SSE bit) so future chips could not include it and software would fall back to regular AES code paths.
- yuhong 13y agoI don't think even all current Intel chips have it either.