Re: [TLS] Comments on

[[e-mail] (Niels Möller )]

Adam Langley <[e-mail]> writes:

> On Thu, Feb 13, 2014 at 5:11 AM, Niels Möller <[e-mail]> wrote:
>> 1. It would be nice with a couple of additional test cases for
>>    AEAD_CHACHA20_POLY1305. In particular for the corner cases of empty
>>    associated data and/or empty plaintext.
>
> Ack. Yoav pulled out the AEAD bit into
> https://tools.ietf.org/html/draft-nir-cfrg-chacha20-poly1305-01 so
> that it's not TLS specific and that's probably the place for this now.

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.

This discrepancy gives me the feeling that I definitely should consider
my implementation as experimental, and not promise any compatibility
until the dust settles.

> (The lengths were originally prefixes of the data. wtc suggested
> moving them to the end so that the AEAD could be computed without
> knowing the length of the data apriori. Although this does lead to the
> possibility of "streaming" APIs which I would discourage as they
> release unauthenticated plaintext and force others to also.)

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.

>>    At least in my implementantation, the length(ad) field causes some
>>    additional complexity, so
>
> Could you elaborate on why knowing the length of the AD is problematic?

Knowing it is not a problem, but inserting it at that place in the
poly1305 input is an annoyingly large proportion of the implementation,
even if the total code size and complexity is pretty small.

I have a low-level streaming interface (I'm considering adding a less
general but more easy to use interface on top), with basically these
functions for encryption (decryption is similar), to be called in order:

set_key
  set_nonce         (one or more times per key)
    update          (process ad, zero or more times per nonce)
    encrypt         (process plaintext, zero or more times per nonce
  digest            (produce the authentication tag, once per nonce)

Note that to keep this interface simple, there's no explicit function to
mark the end of the ad; calling either of encrypt or digest implies the
end of the associated data.

Doing a final length field is very straighforward, it is added
unconditionally by the digest function. However, inserting the ad
length, between the ad and the crypto text, gets a bit more scattered.
If encrypt is ever called, inserting the ad length has to be done for
the first call to encrypt (or more precisely, I do it on the first call
to encrypt providing a non-empty segment of plaintext, since for the
bookkeeping I need to ensure that the ad length has been inserted if and
only if the amount of processed plaintext is non-zero). But in case
plaintext is empty, the ad length instead has to be inserted by the
digest function.

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.

See
https://git.lysator.liu.se/nettle/nettle/blobs/master/chacha-poly1305.c

(And I'm currently *not* confident that this code is correct, since I
lack tests for the corner cases).

> I suspect that some folks will want reduced round variants since it's
> faster and the reduced round versions are holding up to analysis.

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.

Wan-Teh Chang <[e-mail]> writes:

> draft-agl-tls-chacha20poly1305 has been merged into
> http://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-01. But
> the specification of the ChaCha20-Poly1305 AEAD cipher suites did not
> change.

Thanks for the pointer. And here, chacha and chacha-poly1305 are both
specified with a 64-bit nonce.

> I'm also curious to know why. What about
>
>     ad | cryptotext | length(ad)

Adequately explained above, I hope. And the variant you propose should
be as nice and simple to implement as ad | cryptotext | length(cryptotext). Or
for that matter, 

  ad | cryptotext | length(ad) | length(cryptotext)

with both lenghts at the end, if for some reason including both length
fields really is desirable.

Regards, 
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.