[17505] in cryptography@c2.net mail archive
Re: AES cache timing attack
daemon@ATHENA.MIT.EDU (D. J. Bernstein)
Mon Jun 20 12:22:13 2005
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: 20 Jun 2005 01:54:46 -0000
From: "D. J. Bernstein" <djb@cr.yp.to>
To: cryptography@metzdowd.com
http://cr.yp.to/talks.html#2005.06.01 has slides that people might find
useful as an overview of what's going on. In particular, there's a list
of six obstacles to performing array lookups in constant time. People
who mention just one of the obstacles are oversimplifying the problem.
"Hal Finney" writes:
> The one extra piece of information it does return is the encryption of an
> all-zero packet. So there is a small element of chosen plaintext involved.
Known plaintext, not chosen plaintext. I used timings to identify 105
key bits and then compared the remaining 2^23 keys against a known
plaintext-ciphertext pair, namely the encrypted zero that you mention.
One can carry out the final search with nothing more than known
ciphertext: try decrypting the ciphertext with each key and see which
result looks most plausible. It should even be possible to carry out a
timing attack with nothing more than known ciphertext, by focusing on
either the time variability in the last AES-encryption round or the time
variability in the first AES-decryption round.
Of course, most applications have some known plaintext, and some
applications allow chosen plaintext, so even a chosen-plaintext attack
is considered to be a fatal flaw in a cryptographic standard. The user
isn't supposed to have to worry that someone who influences part of the
plaintext will be able to read all the rest.
---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@metzdowd.com
