Re: [TLS] Data volume limits

On 12/15/2015 03:47 PM, Watson Ladd wrote:
>
>
> On Dec 15, 2015 6:08 PM, "Scott Fluhrer (sfluhrer)" 
> <sfluhrer@cisco.com <mailto:sfluhrer@cisco.com>> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Watson Ladd [mailto:watsonbladd@gmail.com 
> <mailto:watsonbladd@gmail.com>]
> > > Sent: Tuesday, December 15, 2015 5:38 PM
> > > To: Scott Fluhrer (sfluhrer)
> > > Cc: Eric Rescorla; tls@ietf.org <mailto:tls@ietf.org>
> > > Subject: Re: [TLS] Data volume limits
> > >
> > > On Tue, Dec 15, 2015 at 5:01 PM, Scott Fluhrer (sfluhrer)
> > > <sfluhrer@cisco.com <mailto:sfluhrer@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
>
> That's correct. And when we crunch the numbers assuming 2^60 is 
> negligible out comes 2^36 bytes. This doesn't hold for ChaCha20.
>

If 2^36 above is about confidentiality, I am getting q<2^34, assuming 
probability of a collision lower than p=2^-60.

2^34*(2^34-1) <  (2^(128-60))/0.316 (that's the formula with 'e', not 
C(q,2)).

q=2^34 blocks is 2^38 bytes (256 GiB). Close enough, although p=2^-60 
could have been higher for higher total bytes before rekey.

> >
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls