Re: [TLS] Rizzo claims implementation attach, should be interesting

[Martin Rex <[e-mail]>]

Martin Rex wrote:
> 
> Nico Williams wrote:
> > 
> > On Tue, Sep 20, 2011 at 3:04 PM, Phillip Hallam-Baker <[e-mail]> wrote:
> > > On Tue, Sep 20, 2011 at 11:21 AM, Martin Rex <[e-mail]> wrote:
> > >> SSL was NEVER designed with a promise that you could multiplex
> > >> data from an evil attack with data from a victim over the very same
> > >> SSL connection and be secure against adaptive chose plaintext
> > >> attacks trying to recover data from the victim.
> > 
> > I wasn't there.  I don't know what it was designed for.  But here's
> > the thing: why shouldn't the designers have assumed that some of the
> > data sent over SSL might be untrusted?  On what grounds would it have
> > been OK to say "no untrusted data, please"?  And where was this
> > restriction documented?
> 
> It is a design limit that should be obvious to the conscious reader
> with background knowledge about cryptography.
> 
> 
> > 
> > But let's grant that restriction.  That would have meant that we
> > should never have allowed IMAP over SSL, for example, and taking the
> > argument to extremes, we should never have allowed HTTP POST over SSL
> > either.
> > 
> > This is really Marsh's point, I think, and I agree with it.
> 
> No, you're entirely confusing things.
> 
> Independent TLS connection states (even for the same cached TLS session)
> do not share traffic encryption and mac keys, so these are protected
> from each other.
> 
> But when you start multiplexing adaptively chosen plaintext from
> an attacker with data from a victim, then you're creating an oracle.
> For TLS cipher suites using block ciphers in CBC mode, there is
> a fixed encryption key for all blocks of data.  Now if the
> block of data for which the attacker wants to recover the exact
> plaintext is sufficiently short (e.g. DES-based = 64-bit), and this
> block of contains a small amount of unknown entropy, and the attacker
> is permitted sufficient guesses at the original plaintext, the attacker
> may perform a guessing attempt at that unknown victim data.

What I forgot: if the attacker knows the IV ahead of time (the IV that will
be used to CBC-encrypt the attackers chosen plaintext) or if the attacker can
force the IV value that will be used, then the guessing will become
extremely effective for low-entropy unknowns (provided that the attacker
knows the IV that was used for the unknown, but for CBC that is well known
whenever that IV is either explicit or when CBC is used and the unknown
io in a later block.


-Martin