I'm continuing to reply to myself... It's the recurring question on fixed size versus varying size of certain inputs and outputs.
[email protected] (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. If it's fixed, then the abstraction can't be used as is in the testsuite, because there are testcases at least for gcm, which try varying the nonce size. Could be solved by passing an extra function pointer for those tests (or define a nettle_aead struct for each tested size, but that seems a bit awkward). > nettle_hash_digest_func *digest; Using nettle_hash_digest_func implies a size argument, since nettle's digest functions allow truncation. And, e.g., eax is specified with the "tag length" tau as a security parameter, so the underlying eax_digest function ought to have a size parameter. But varying the size is a bit questionable in the context of an "abstract" aead algorithm; there the digest size ought to be fixed, toghether with nonce size and key size, as an "instantiation" of a more general algorithm. So should we have a separate type, typedef void nettle_aead_digest_func(void *ctx, uint8_t *dst); for this digest function pointer? > I think it may be a good idea to implement chacha-poly1305 before doing > this abstraction, so there's at least three different aead mechanism to > test it with. I've started on this, and it seems nice and easy. But I stumbled on the above interface issues. 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
