Re: [Cfrg] I-D Action: draft-nir-cfrg-chacha20-poly1305-01.txt

[Yoav Nir <[e-mail]>]

On Mar 12, 2014, at 4:57 AM, Ted Krovetz <[e-mail]> wrote:

> Hello Yoav,
> 
> Nice work on draft-nir-cfrg-chacha20-poly1305-01.txt. It's a useful document. I wonder, though, if endian conventions are clear enough. What exactly is a little-endian integer? (I thought there was only one kind of integer.)

I don’t know what a 32-bit integer is, either. I thought the list of integers extended to infinity. I guess I should change the text to say that it’s a little-endian representation of integers limited to 32 bits.

> I think you mean that keys, etc, residing in memory are read little-endian, 32-bits at a time. But, what if these quantities do not come from memory? What if the nonce, or key, or counter happens to be a computed value and resides in registers?

That is exactly what happens in both ESP and TLS (and I assume SSH). Some KDF churns out an octet string, and that has to be used as keys. So if my draft says that the key to ChaCha is 8 little-endian 32-bit integers, what I mean is that the 32 octets (or 256 bits) are taken 4 (or 32) at a time, and taken to be a 32-bit little-endian representation of an integer. This produces that 8 integers that are the input to ChaCha.

> When exactly do these need byte reversal? As an example, when you talk about the counter being 1, is that 00:00:00:01 in memory, which then becomes 01:00:00:00 in a register, or vice-versa? I was able to figure it out by looking at your examples, but it might be better if it were made clearer and didn't *need* looking at examples.

I’m guessing you didn’t attend the JSON meeting on Friday, where someone (I don’t remember who) said something to the effect that real developers look first at the examples rather than read ABNF. Some cheered (I know I did)

Anyway, the block counter is internally generated, so it’s simply a number regardless of the internal architecture of the machine. The nonce in ChaCha, however, and the blocks in Poly1305 are read from an octet string as if they were a 32-bit little-endian representation of integers.

> One approach you might consider is defining the interfaces as taking plain old integers, but then writing a note that explains how big-endian and little-endian systems would interact with such an interface to get standard behavior.

It could be a good idea. I’ll see if it fits for the next revision.

> Damn Intel for making the world primarily little-endian! It's such a pain.

I don’t know. This is pretty nifty:

int main(int argc, char** argv)
{
    long long int num;
    long long int* llp;
    long int* lp;
    int* p;
    short* sp;
    char* cp;

    num = 7;
    llp = &num;
    lp = (long*) llp;
    p = (int*) llp;
    sp = (short*) llp;
    cp = (char*) llp;

    printf(“%lld %ld %d %hd %hhd\n”, 
        *llp, *lp, *p, *sp, *cp); 
}

Yoav