Stephan Neuhaus <[EMAIL PROTECTED]> writes: >Concerning the practical use of AES, you may be right (even though it would >be nice to have some advice on what one *should* do instead).
Definitely. Maybe time for a BCP, not just for AES but for general block ciphers? >But as far as I know, resistance to such attacks was one of the design goals >for AES. I find it pretty alarming that in spite of all the review that AES >got, this design goal was not met, and in an exploitable fashion to boot. Well, it depends on what your design assumptions were. I assume AES went with a basic Newtonian physics-level approximation of the world that's good enough for most cases without going into so much specialised detail that it becomes unworkable. In fact I'd say it's actually not possible to certify resistance to timing attacks across all possible CPUs, because it'll always be possible to find some oddball CPU for which an AES-critical instruction somewhere has some weird characteristic that helps in an attack. Lets say you want constant timing for at least the most common CPU family, x86. But that's way too broad, so you restrict it to Intel x86. That still covers far too many architectures to be useful, so you say Intel P4 x86. But there are multiple P4 cores that all perform differently, so you decide on the Northwood core. Now, which stepping of that core do you want to use? So in the end you've got an algorithm design that happens to be resistant to timing attacks on the D0 stepping of a Northwood-core Intel P4. Anything else and all bets are off. This doesn't seem very useful to me. >I think this says more about the standardization and review process than >about AES. I think the standardisation process went about as well as can be expected, given Newtonian physics-level assumptions about how CPUs work. Once you start getting into special relativity-level analysis, the model gets a bit more precise, but you also need a small book of explanatory notes for each situation, and it becomes impossible to ship any normal product if you require per-core-stepping tuning. So I'll stick by my comment that the only really practical way to address this is with "Don't do that, then". Now, as you point out, we need a BCP on what not to do. I'd suggest not just a basic "don't do this" but also a "do do this", along with a list of common solutions that get it right: SSL/TLS, SSH, IPsec, etc etc. Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]