| > Frankly, for SSH this isn't a very plausible attack, since it's not | > clear how you could force chosen plaintext into an SSH session between | > messages. A later paper suggested that SSL is more vulnerable: | > A browser plugin can insert data into an SSL protected session, so | > might be able to cause information to leak. | | Hmm, what about IPSec? Aren't most of the cipher suites used there | CBC mode? If it doesn't key each flow seperately, and the opponent | has the ability to generate traffic over the link, which isn't | unreasonable, then this would seem feasible. And then there's openvpn, | which uses SSL for the point-to-point link, thus probably vulnerable, | more vulnerable than a browser. I am also aware of SSL being used | many places other than browsers and openvpn. Just being able to generate traffic over the link isn't enough to carry out this attack. You have to be able to get the sender to encrypt a chosen block for you as the first thing in a packet. How would you do that? Suppose there was an "echo" command that would cause the receiver to send back (within the encrypted channel) whatever data you asked. Well, how do you get an "echo" command inserted into the encrypted, presumably authenticated, flow going back the other way?
The browser SSL attack could work because plugin code runs *within* the browser - which knows the key - and it can add material to the "red" (plaintext) connection data. How do you propose mounting the attack given only access to the "black" connection data? I'm not saying there couldn't be such an attack, or that it's not worth defending against - just that it appears to be very hard to pull off. -- Jerry --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]