[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 world. 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. Perry 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]