Re: [TLS] Comments on draft-nir-cfrg-chacha20-poly1305-02

[Adam Langley <[e-mail]>]

On Thu, May 8, 2014 at 12:32 AM, Niels Möller <[e-mail]> wrote:
> Is this something you'd want to address? After all, high performance is
> one of the primary design goals for both chacha and poly1305. The easiest
> way I see is to change the formatting for authentication to
>
>   ad | pad1 | cryptotext | pad2 | length(ad) | length(cryptotext)

I think this might be a good idea, thanks!

I happen to be meeting with some hardware folks tomorrow (although not
about this) and I'll see whether they agree that this would be useful.
(Although I'm less sure about moving the lengths to the end.)

> There are some other possibilities, taking advantage of the fact that
> poly1305 has an unambibuous encoding for short blocks. E.g, if the ad is
> the single byte "a", 0x61, zero-padding produces the poly1305
> coefficient 0x10000000000000061, but one could also represent it as
> 0x161, as is specified for a final, short, block in poly1305-aes. With
> some care, I think one could even drop both length fields. What's needed
> is to use the poly1305 short block encoding for the final ad and crypto
> text blocks, and in addition make sure that the ad *always* is
> terminated with a short block, by adding an empty block (poly1305
> coefficient 0x1) between ad and cryptotext in case the ad length is a
> multiple of 16.

My feeling is that this is getting too complex for the resulting benefit.

> Another minor point: The unused 32 bytes of the first chacha block
> (after the 32 bytes used for the poly1305 subkeys), could they be
> considered a separate (and optional) output? When chacha-poly1305 is
> used in openssh, they encrypt the packet length field separately, and
> they seem to be using another instance of chacha for that, with an
> independent key. Which seems a bit unnecessary when there are plenty of
> left over keystream bytes from the chacha-poly1305 instance they use for
> the message payload.

Implementations could certainly extract this if they wished, although
I'd like to stay in the RFC 5116 framework for AEADs in the spec.

For SSH's use, I guess this would complicate their AEAD implementation
because they would need to break it up: they need to calculate the
first block to decrypt the length and then they can figure out what
the ciphertext is. Actually, if they were going to use the leftover
keystream bytes from the first block for the length then I would
imagine that they would use a separate ChaCha call to calculate it and
then, if they decrypt the length and find they have a whole record to
process, call the AEAD function, which will redundantly calculate the
first block again.


Cheers

AGL

-- 
Adam Langley [e-mail] https://www.imperialviolet.org