Steven M. Bellovin writes: > Dan Bernstein has a new cache timing attack on AES: > http://cr.yp.to/antiforgery/cachetiming-20050414.pdf
This is a pretty alarming attack. Bernstein was actually able to recover the AES key using a somewhat artificial server which reported its own timing to do an AES operation. In principle the same attack would be possible on a typical remote server, using a larger number of requests to average out timing variations. He also had some critical things to say about the AES selection process, which apparently dropped the ball on this issue. Other ciphers got dinged for nonconstant execution time, but no one thought that cache misses would be that significant. Dan has more information at http://cr.yp.to/mac.html, including graphs showing the variability in timings for various implementations at http://cr.yp.to/mac/variability1.html and http://cr.yp.to/mac/variability2.html, and his own attempt at a (nearly) constant-time AES implementation as part of his poly1305-aes MAC function. It would be interesting to see how the speed of his AES implementation compares to that of other widely used versions like Brian Gladman's. How much speed penalty do you pay to get the constant speed? As Dan notes, you can easily make a slow AES that runs at constant speed, but a fast one is far more difficult. I also wonder how it would compare to take something like Gladman's (supposing it is faster than Bernstein's), estimate its worst case running time, and then add a delay using a high-res timer from the operating system to make it always take the same time. Hal Finney --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]