Re: [TLS] Comments on

[Adam Langley <[e-mail]>]

On Fri, Feb 14, 2014 at 3:42 AM, Niels Möller <[e-mail]> wrote:
> Thanks for the pointer. This specifies a 96-bit nonce, both for chacha
> and chacha20-poly1305. I'm a bit confused by the different definition
> of chacha, with a 32-bit counter and 96-bit nonce, rather than 64 bits
> each like in the chacha spec.

It appears that IPSec wants the extra 32 bits of nonce. Although this
is an important change in definition it doesn't actually change the
wire-format for TLS because the record-length limit means that those
bits are always zero anyway in both cases.

> I agree that most applications shouldn't use streaming operation, at
> least for decryption. But I also think there are valid usecases for
> streaming operation, e.g., processing a large file where you really want
> a single indication of autenticity for the complete file. In GNU Nettle,
> which is a general purpose but pretty low level crypto library, I'd like
> to support aead streaming operation whenever possible.

Keep in mind that it affects more than just your users. By making
streaming designs easy you allow people to make bad designs (like CMS)
that force streaming designs on others in order to handle large files.
The point of AEADs is that it's an easier primitive to use. It would
be doubly unfortunate if they ended up with a sharp edge by returning
unauthenticated plaintext.

> For some numbers, my current implementation is 101 non-comment lines of
> C (on top of chacha and poly1305 building blocks). Of those, 20% of the
> lines and 80% of the if statements are for the insertion of the ad
> length.

Thanks. I understand why omitting the length would be easier for you
and it doesn't deeply bother me either way. The WG can figure it out.

However, my preference would be to leave it as is because I've already
got code that does it that way and I don't believe that streaming is
something that should be made easy.

> I see. Vaguely related question: Do you see any need for 128-bit chacha
> keys? They're not really in the very short chacha paper, but they are in
> the reference implementation.

Since they are no faster I don't believe that anyone will want to
support them. However, I may be wrong about that.


Cheers

AGL