Hi On 16/05/2016 11:15, "Aaron Zauner" <a...@azet.org> wrote:
>Hi Kenny, > >> On 16 May 2016, at 16:48, Paterson, Kenny <kenny.pater...@rhul.ac.uk> >>wrote: >> >> Maybe the confusion is this: in your authenticity attack, you do recover >> the GHASH key, and the effect is catastrophic. In the confidentiality >> attack, one can recover plaintexts for the records with repeated nonces, >> but not the encryption key. The effect may be bad - but it's perhaps not >> as catastrophic in practice as the authenticity attack. > >Ah, I see. Yes and we do not consider this in our paper at all. Maybe we >should? Not sure how practical this is. Good to get this cleared up. Yes, it's eminently practical to recover the two plaintexts from their XOR assuming you have a good language model (e.g. one can use a Markov model with a suitable memory length; this would work for HTTP records, natural language, etc). To code it all up is not trivial - I currently set it as a final year project for our undergrad students, for example. The paper by Mason et al from CCS 2006 gives a nice account of the whole business. > >> Think about it this way: for your injection attack, you need to recover >> the CTR keystream - otherwise you couldn't properly AES-GCM-encrypt your >> chosen plaintext record for the injection. But if you recovered the >> keystream as part of your attack, then you've also recovered the >>plaintext >> for the original record. >> >> Or maybe in your injection attack you were assuming you already *knew* >>the >> plaintext? That would make sense, I guess - a lot easier then to recover >> the keystream than doing the "undoing the XOR" attack needed to recover >> P_1 and P_2 from P_1 XOR P_2. > >The first step of our attack involves attacker controlled content. So yes >(phishing, unauthenticated HTTP, selective company DPI etc.). In our >example we use a local proxy to carry out the attack. I hope I can post a >full version of the actual paper and PoC to this thread soon. OK, makes sense now. Cheers Kenny > >Aaron _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
