nisse@lysator.liu.se (Niels Möller) writes:
Q: Should the nonce size be fixed?
A: Yes. Motivation: For a given key, fixed nonce size is good enough for RFC 5116. It's unclear if there are use-cases for varying the nonce size, and if needed one can define separate nettle_aead objects differing only in nonce size.
I'm still having some difficulty figuring out what really is the Right Thing here. I think there are two usecases, with somewhat different requirements.
1. General code which is written to work with any aead algorithm. This has to use nonces of size aead->nonce_size, because there's no interface to query what other nonce sizes might be valid (we have the option of adding some n_min and n_max values, though). So here, a length argument for set_nonce is useless.
2. Code which uses a single aead algorithm, say eax-aes128, but uses the nettle_aead abstraction in order to use the user-friendly to-be-defined aead_* functions, say, a aead_encrypt_message to do all work for processing one message. That code may well know that eax supports arbitrary nonce sizes. Then it would either need a way to pass a length argument to set_nonce, or a supported way to call some other algorithm specific function to set the nonce.
For now, I'm leaving it as fixed size, but I might change my mind before release.
Related question is the length for the digest method. I'm leaning towards leaving that in, even though I'd expect that to be useless for almost all applications using aead. The reason is consistency with other nettle functions; all other hash and mac algorithms support a length argument, to truncate the digest to any desired smaller size.
I've pushed my aead changes to the repo now. Currently defined instances are
nettle_gcm_aes128 nettle_gcm_aes192 nettle_gcm_aes256 nettle_chacha_poly1305 nettle_eax_aes128
Comments highly appreciated.
For chacha_poly1305, we really need additional testcases, in particular for corner cases like empty plaintext or empty authenticated data.
Regards, /Niels