Re: More info in my AES128-CBC question

| > 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 majordomometzdowd.com

On Wed, May 09, 2007 at 06:11:03PM -0400, Leichter, Jerry
wrote:
> 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.

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)

-- 
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 johnsubspacefield.org.