| > Just being able to generate traffic over the link isn't enough to | > carry out this attack. | | Well, it depends on if you key per-flow or just once for the link. If | the latter, and you have the ability to create traffic over the link, | and there's a 1-for-1 correspondence between plaintext and encrypted | packets, then you have a problem. I have no clue what this means. | Scenarios include: | | Private wifi network, you are sending packets at a customer from | unprivileged node on internet; you want known plaintext for the key | used to secure the wifi traffic, or you want the contents of his | connection. | | Target is VPN'ed into corporate headquarters, you are sending packets | at them (or you send them email, they download it from their mail server) Again, we're talking about a particular attack, which requires (a) not known, but chosen plaintext; (b) more, *adaptive* chosen plaintext: You have to be in a position to choose the plaintext for the next block that will be encrypted *after* you've seen the ciphertext of the previous block.
Nothing like e-mail is going to work, since even supposing you could grab the last packet on the link and get your mail message to be the next thing to get sent over the link: The first block of a mail message as a server delivers it is never going to be completely under your control, and in fact it's unlikely you can control any of it. (If what you meant by "1-for-1 correspondence between plaintext and encrypted packets", then I guess that mail doesn't come close.) You can certainly come up with artificial scenarios where such an attack would work. For example, suppose you know that the victim it tailing some file, and you can write to that file. Then by appending to the file you are inserting chosen plaintext into his datastream. Maybe you could come up with some analogous attack around an RSS feed, but I'm skeptical - you have to be able to choose every byte of the first block or the attack is impossible. Further, suppose you can choose the first block, but only some fraction of the time. Well ... without some other signal, you can't tell if the first block failed to match your target because your target was wrong, or because you didn't manage to get your block in. So now you have to try repeatedly. What was always a brute- force search just got multiplied by some factor. Again, it's not that this isn't a potentially significant attack. It's that the combination of special circumstances you need to pull it off - a block known to have high value; a small enough set of possible values for that block that you have hope of guessing it correctly before the key is reused; enough pauses in the datastream to actually let you try enough probes to get a significant probability of confirming a guess; the ability to insert random packets into the plaintext repeatedly without it being noticed - limits the plausible attack scenarios to a rather small set. One can worry about everything or one can try to field real systems. -- Jerry | -- | Kill dash nine, and its no more CPU time, kill dash nine, and that | process is mine. -><- <URL:http://www.subspacefield.org/~travis/> | For a good time on my UBE blacklist, email [EMAIL PROTECTED] | --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]