AES cache timing attack

[Peter Gutmann]

Stephan Neuhaus <neuhaus at st.cs.uni-sb.de> 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 majordomo at metzdowd.com