More info in my AES128-CBC question

[Leichter, Jerry]

| > 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 john at subspacefield.org.
| 

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com