Re: [Cfrg] ChaCha20 and Poly1305 for IPsec

[David McGrew <[e-mail]>]

On 01/21/2014 05:08 PM, Adam Langley wrote:
> On Tue, Jan 21, 2014 at 4:53 PM, Yoav Nir <[e-mail]> wrote:
>> Looking into GCM, I see two other things:
>>   1. The lengths there are big-endian ("...a 64-bit string containing the nonnegative integer describing the number of bits in its argument, with the least significant bit on the right.")
>>   2. The lengths there are the number of bits, not bytes.
>>
>> Big-endian always seemed to me to be more "natural" because most binary protocols transmit numbers that way, but I don't think there's any reason to count bits, is there?
> There might be an implementation of GCM that supports bit lengths that
> are not a multiple of 8, but I'm not aware of it.

I'm not aware of it either, if it exists.

With GCM, we took this strategy: make the inputs and outputs octet 
strings, since that is what really matters in the real world, but then 
use the number of bits in the computation of the authentication tag 
rather than the number of bytes, so that it would be possible for 
someone else to define a bit-oriented version of the algorithm if they 
really need to.

> I think little-endian makes more sense in a ChaCha20-Poly1305 AEAD
> because everything else in the AEAD (ChaCha and Poly1305) is handled
> as little-endian.
>
> (I've also done enough implementations of the arithmetic that I find
> little-endian to be preferable in general, but that might just be
> brain damage.)
>

For what it is worth, little endian has a legitimate advantage in that 
enables better pipelining of multiplications.   But I think this is a 
six-or-half-dozen issue.

David

> Cheers
>
> AGL
>