AES cache timing attack

[Jerrold Leichter]

| Uhh, that wasn't really what I was after, that's pretty much textbook stuff,
| what I wanted was specifically advice on how to use block ciphers in a way
| that avoids possibilities for side-channel (and similar) attacks.  I have some
| initial notes that can be summarised as "Don't let yourself be used as an
| oracle" that I was planning to add after I've fleshed them out a bit.
It strikes me that block ciphers in *communications*get used in two 
different contexts:

	- With a long-lived key.  This is in protocols like Kerberos,
		where the long-lived key is used as part of a mechanism
		to produce a session key.  In most more recent protocols,
		some combination of D-H or public key plays this role.

	- With a session key.

Usage in first of these may be subject to Bernstein's attack.  It's much 
harder to see how one could attack a session key in a properly implemented 
system the same way.  You would have to inject a message into the ongoing 
session.  However, if the protocol authenticates its messages, you'll never 
get any response to an injected message.  At best, you might be able to 
observe some kind of reaction to the injected message.  But that's a channel 
that can be made very noisy, since it shouldn't occur often.  (BTW, if you use 
encrypt-then-authenticate, you're completely immune to this attack, since the 
implementation won't ever decrypt the injected message.  Of course, there may 
be a timing attack against the *authentication*!)

By their nature, the first class of uses don't usually require the ultimate in 
performance.  Since they receive and respond to small messages involving the 
encryption of a small amount of data, the encryption portion of the what they 
do is rarely the major time cost.

If this dicotomy holds up, it leads to a simple recommendation:  Use a 
constant-time implementation in the first role; use the highest-performance 
implementation in the second role.
							-- Jerry


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com