> -----Original Message----- > From: Watson Ladd [mailto:watsonbl...@gmail.com] > Sent: Tuesday, December 15, 2015 5:38 PM > To: Scott Fluhrer (sfluhrer) > Cc: Eric Rescorla; tls@ietf.org > Subject: Re: [TLS] Data volume limits > > On Tue, Dec 15, 2015 at 5:01 PM, Scott Fluhrer (sfluhrer) > <sfluh...@cisco.com> wrote: > > Might I enquire about the cryptographical reason behind such a limit? > > > > > > > > Is this the limit on the size of a single record? GCM does have a > > limit approximately there on the size of a single plaintext it can > > encrypt. For TLS, it encrypts a record as a single plaintext, and so > > this would apply to extremely huge records. > > The issue is the bounds in Iwata-Ohashai-Minematsu's paper, which show a > quadratic confidentiality loss after a total volume sent. This is an > exploitable > issue.
Actually, the main result of that paper was that GCM with nonces other than 96 bits were less secure than previous thought (or, rather, that the previous proofs were wrong, and what they can prove is considerably worse; whether their proof is tight is an open question). They address 96 bit nonces as well, however the results they get are effectively unchanged from the original GCM paper. I had thought that TLS used 96 bit nonces (constructed from 32 bit salt and a 64 bit counter); were the security guarantees from the original paper too weak? If not, what has changed? The quadratic behavior in the security proofs are there for just about any block cipher mode, and is the reason why you want to stay well below the birthday bound. However, that's as true for (say) CBC mode as it is for GCM _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
