Timing attack against AES

Werner Koch wk at gnupg.org
Tue May 24 10:26:52 CEST 2005


Ryan, thanks for explaining this.  I agree with you.

Let me add that this is a classical type of side-channel attack and
nothing really new.  It is a general problem to hide things from other
processes when sharing hardware.  It is possible to make it hard but
there won't never be perfect solution on a general purpose computer.
Disallowing access to fine grained timing facilities will somewhat
help but is inconvenient for other applications.

If one really cares about security, running any unrelated process to
the encrytion software is dangerous as it opens a lot channels to
snoop keys.  For public key encryption it is in most cases not that
critical because only the session keys are at stake and there are
easier ways to get to the plaintext.  Using private keys (i.e.
decrypting or signing messages) on a multi-user box is something one
should avoid under all cases because a compromise is not limited to
one or several sessions but extends to the past and future use of that

If you have really valuable things, better use dedicated hardware
hardened to protect keys.  Today this may even require changes at the
lowest levels to replace the simple true/false logic elements.  There
are many papers on how to harden smartcards and HSMs against side
channel attacks and those techniques are already in use.

One interesting question with the recent AES and Hyperthreading RSA
attacks is whether they can be used to poke holes into forthcoming
Digital Restriction Management systems (TCPA et al.).  The Fritz chip
might be up to what the card industry has learned the hard way but
those systems also need to do many crypto things by "trusted" software
on a general purpose CPU.



More information about the Gnupg-users mailing list