4 ms·
He's right; implementing plain constant-time AES can be done without AES-NI, but is by no means easy or obvious.
by pbsd 13y ago
He'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
- tptacek 13y agoThis is a cool paper, but I don't see 14cpb GHASH in it; their best timings for large packets in constant time are over 20cpb.