Hi,
On Thu, 13 Feb 2014 09:38:30 +0100 nisse@lysator.liu.se (Niels Möller) wrote:
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.
[...]
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 :)
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.
The RFC says:
Each AEAD algorithm MUST provide a description relating the length of the plaintext to that of the ciphertext. This relation MUST NOT depend on external parameters, such as an authentication strength parameter (e.g., authentication tag length). That sort of dependence would complicate the use of the algorithm by creating a situation in which the information from the AEAD registry was not sufficient to ensure interoperability.
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.
Also the RFC doesn't specify an interface for such tags ("digests") at all - they are part of the ciphertext.
So the "RFC way" would be renaming "digest" to "finish" and have some way to signal a larger output buffer is needed; perhaps similar to the z_stream interface. I'm not saying that would be a good idea :)
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.
To handle such algorithms well it may be necessary to ask for a fixed AD buffer in the beginning, which has to be valid while the plain/cipher text is processed.
Also some algorithms may need to know the length of the plain text in advance (CCM for example).
regards, Stefan