[EMAIL PROTECTED] (Peter Gutmann) writes:
> [EMAIL PROTECTED] ("Hal Finney") writes:
>>Steven M. Bellovin writes:
>>> Dan Bernstein has a new cache timing attack on AES:
>>>       http://cr.yp.to/antiforgery/cachetiming-20050414.pdf
>>This is a pretty alarming attack.  
> It is?  Recovering a key from a server custom-written to act as an oracle for
> the attacker?  By this I don't even mean the timing-related stuff, but just
> one that just acts as a basic encryption oracle.  Try doing that with TLS or
> SSH, you'll get exactly one unrelated packet back, which is the connection
> shutdown message.  So while it's a nice attack, section 15 should really be
> simplified to:
>   Don't do that, then.

Sadly, it is very hard to avoid chosen plaintext attacks in the real

Consider, for example, the various new wireless security protocols
that have been proposed. For many of them, it should be simple to send
chosen data from the internet to a machine on the wireless network. No
established connection is needed -- you don't care if it rejects the
packets, only that the router sends them -- and if you are in a
position to listen in so you can exploit the stolen key, you are also
in a position to capture as much ciphertext resulting from the chosen
plaintext as you like. Adaptive attacks are quite straightforward in
this scenario.

This is only one of a number of instances in which it is fairly
straightforward to inject data in the real world. Lots of VPN
scenarios make it possible.

I'd say we should probably be thinking of ways to make sure that AES
implementations are safe from this kind of attack.

PS Credit where credit is due -- the wireless network example came
from Thor Simon.

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to