On Tue, Dec 15, 2015 at 3:08 PM, Scott Fluhrer (sfluhrer) < sfluh...@cisco.com> wrote:
> > > > -----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); TLS 1.3 uses a 96-bit nonce constructed by masking the counter with a random value. 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. The birthday bound here is 2^{64}, right? -Ekr > 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
