Messages in this thread | | | Date | Sun, 15 Dec 2013 17:19:48 -0500 | From | Theodore Ts'o <> | Subject | Re: Replace /dev/random input mix polynomial with Brent's xorgen? |
| |
On Sun, Dec 15, 2013 at 03:34:59AM -0500, George Spelvin wrote: > > I'm not convinced we need to worry about cache timing attacks, since > > they typically involve a chosen plaintext attack and a fixed key --- > > and the attacker isn't going to know what we are going to be > > encrypting, let alone be able to chose the plaintext. > > You're describing standard key-recovery attacks. For /dev/random, > just knowing the *ciphertext* constitutes a successful attack.
Um, no. The *ciphertext* is the output. The attacker can get all of the ciphertext he or she wants by reading /dev/random (although we'd probably do some folding as we currently do so the attacker won't even get all of the ciphertext). What the attacker has to be able to do is given some of the ciphertext bits, be able to predict future ciphertext bits given some construction which uses AES as the basis.
For example, using something simple (we'd probably using something more complicated, such as Davies-Meyer), show me a cache timing attack where the attacker can get to see arbitrary values of:
R_X = AES(KEY, I+X)
But where the attacker does not know KEY, *or* I, but can get to see R_X for values 0 < X < N. The attacker has to be able to predict R_(N+1).
Show me a cache timing attack given this scenario, and I'll be convinced. I believe this is **harder** than a standard key-recovery attack, since the attacker doesn't get to choose the plaintext. And if you can't choose the plaintext in order try to recover the key, please tell me how use can use cache timings in order to predict R_(N+1), or even some bits of R_(N+1)? Especially given that any good crypto algorithm is designed so that even one or two bits change in the key or the plaintext will result in massive changes in the ciphertext....
- Ted
| |