Re: [TLS] [Technical Errata Reported] RFC5288 (4694)

[Aaron Zauner <[e-mail]>]

Hi Kenny,

> On 16 May 2016, at 16:18, Paterson, Kenny <[e-mail]> wrote:
> 
> Hi Aaron,
> 
> If AES-GCM ever generates two ciphertexts using the same key and the same
> 96-bit nonce, then the underlying CTR-mode keystreams will be the same.
> XORing the ciphertexts together then produces the XOR of the plaintexts,
> from which the two individual plaintexts can be recovered (usually) with
> high probability using standard techniques (see the paper by Mason et al
> at CCS 2006 for a full account of this step).
> 
> In the TLS context, this means using the same 64-bit nonce_explicit in a
> given connection - because then opaque salt will be the same 32-bit value.
> 
> This condition is detectable by an adversary because the nonce_explicit
> part is sent on the wire (the clue is in the name!).
> 
> You don't need to know the full 96-bit nonce to carry out the attack.

Yes, I understood that, of course. But:

> Once you've recovered a plaintext, you can also recover the corresponding
> CTR-mode keystream. Together with the integrity key, this now enables
> packet forgery attacks for arbitrary plaintexts (of length limited by that
> of the known keystream).

Right. Joux's attack doesn't recover a plaintext of the actual TLS session, we attack GHASH in this case and factor possible candidate polynomials of the /authentication key/. In this context I assume 'confidentiality compromise' with: somebody can recover plaintext from captured TLS records. At least in our attack this isn't the case. We're merely able to inject malicious content. Am I amiss? Or am I just confused about nomenclature?

Thank you,
Aaron