Stefan Bühler <[email protected]> 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 -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
