Stefan Bühler nettle-bugs@stbuehler.de writes:
The RFC explicitly supports a range of nonce sizes; I think the overhead of supporting them is so small that I don't see why not to just add it and be done with it :)
Maybe. We'd then need all of a minimun, a maximum, and a default/recommended value. I don't think we should have what the rfc calls randomized or stateful algorithms at this level.
What should the minimum value be? Both eax and gcm could have minimum value 0 and maximum value UINT_MAX, since they both hash the nonce as needed. Actually using an empty nonce means that one can process only a single message with each key.
The gcm spec allows arbitrary nonce size, and with size != 12 the nonce is hashed. But I don't know if this is a feature anyone is using? RFC 5116 specifies a fix size of 12 bytes for gcm. (Restricting to 12 bytes would make it natural to support auto-increment of the nonce).
I'm not sure I'm reading this correctly, but to me this means that an AEDA algorithm could have an "authentication tag length" parameter, but would have to pad it to the maximum tag length it supports, as otherwise the length of the ciphertext would depend on that parameter, making such parameter completely useless.
I think that with different tag lengths, you would have a separate aead algorithms in the rfc definition for each possible tag size. At least, that's one way to make sense of it.
Also the RFC doesn't specify a "streaming" interface (afaik); for example an AEAD algorithm could process the plain text data before the additional data.
Algorithms of interest do support streaming mode, though, and I think it's viewed as a desirable feature.
Also some algorithms may need to know the length of the plain text in advance (CCM for example).
I'm not really familiar with ccm, I've only read the critique of it in the eax paper. But that sounds like it's killing streaming operations.
Regards, /Niels