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

[Marsh Ray <[e-mail]>]

On 09/20/2011 04:31 PM, Martin Rex wrote:
>
> 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.

It's only an oracle if there is information revealed to the attacker. If 
that's the case, it should be considered a cryptographic weakness.

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

Yeah CBC sucks, especially with predictable IVs.

It's a weakness.

> It was not a design requirement at that time, so that property does
> not exist in the original SSLv3 (and TLS) design.  When cipher suites
> with stream ciphers are not affected, then this is a lucky coincidence,
> not a result of a conscious design (based on a requirement).

Well where does that reasoning end?

If a defect were found in TLS which could be exploited using long 
strings of the letter 'A', would you say that the protocol was never 
"designed to resist long strings of the letter 'A' attacks"?

This protocol is something called "IETF Transport Layer Security". It's 
not "Security for Data That M. Rex Feels Web Browsers Should Be Able to 
Transport Securely". :-)

- Marsh