On Sun, May 15, 2016 at 3:52 PM, Peter Gutmann <pgut...@cs.auckland.ac.nz> wrote:
> Aaron Zauner <a...@azet.org> writes: > > >What do you think nonce stands for? > >https://en.wikipedia.org/wiki/Cryptographic_nonce > > Well there's your first mistake, you're using Wikipedia as a reference. > "nonce" is from medieval English, and predates modern cryptography and IVs > by > about 800 years. > Sure, I wouldn't cite Wikipedia in an academic publication, but it's what pops up first if someone looks for "nonce" via a Google search. That was my point. In general I think the wording should be more clear and a little less of crypto-only nomenclature, thus -- maybe -- more convenient for engineers. I suspect this was one of the issues with the document and why we found vulnerable implementations in the first place. If you read carefully and do your home-work the RFC in current form pretty much tells you that you shouldn't re-use the nonce. Compared to TLS 1.3 and the ChaCha20/Poly1305 document (and my OCB draft): the construction does not prevent implementers from re-using the same nonce by mistake. Ideally it would be handled in such a way that human error results in non-interoperable implementations, like with said drafts and 1.3. But as noted: it'll probably cause massive breakage among deployed implementations and may even be the cause for more security issues with implementations to pop up. I know that the word "nonce" does have another meaning as well (BTW I'm not a native english speaker, as you may have guessed). But do you think that is really relevant in this case? If so, could you suggest better wording for this specific paragraph? > > >In TLS nonce reuse allows us to attack the authentication key of GCM. Not > the > >actual master secret. There's no direct break of the confidentiality, > > If you reuse the IV/nonce in GCM (or more specifically CTR mode), you > repeat > the cipher stream. An XOR makes it go away, so you lose any > confidentiality. > This document is on TLS cipher-suites, not AES-GCM in general. This attack isn't applicable here for various reasons. But I agree that the errata could be clearer here. What'd be your suggestion as an addition or change? I'm sure the relevant editors will be willing to amend/change my wording in this errata. More feedback is always appreciated. I suggest people on this list comment as much as they think is relevant to this errata, we should get it perfect this time around. It should be as clear as possible and be understood by everyone - otherwise the errata doesn't make any sense. Thanks, Aaron
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
