Protecting against the cache-timing attack.

[D. J. Bernstein]

Jon Callas writes:
> So let's conduct a small thought experiment. Take the set of timings T, 
> where it is the timings of all possible AES keys on a given computer. 
> (It's going to be different depending on cpu, compiler, memory, etc.) 
> Order that set so that the shortest timing is t_0 and the longest one 
> is t_omega. Obviously, if you delay until t_omega, you have a 
> constant-time encryption.

A network packet arrives during your AES computation, takes tens of
thousands of cycles to handle, and knocks a few of your table lines
(perhaps chosen by a remote attacker?) out of both L1 and L2 cache.

Part of the problem here is that t_omega is huge, forcing a huge delay.
Another part of the problem is that your timings are now interacting
with the timings of other processes. An extreme form of this effect is
illustrated by the very fast hyperthreading attack; I'm sure that some
bored undergraduate will figure out a remote exploit for a less extreme
form of the effect.

Section 13 of my paper discusses a solution to the interrupt problem,
but that solution requires massive software changes. I'm not aware of
simpler solutions.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

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