Re: [TLS] Data volume limits

[Watson Ladd <[e-mail]>]

On Dec 15, 2015 6:08 PM, "Scott Fluhrer (sfluhrer)" <[e-mail]>
wrote:
>
>
>
> > -----Original Message-----
> > From: Watson Ladd [mailto:[e-mail]]
> > Sent: Tuesday, December 15, 2015 5:38 PM
> > To: Scott Fluhrer (sfluhrer)
> > Cc: Eric Rescorla; [e-mail]
> > Subject: Re: [TLS] Data volume limits
> >
> > On Tue, Dec 15, 2015 at 5:01 PM, Scott Fluhrer (sfluhrer)
> > <[e-mail]> 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.
>