Nikos Mavrogiannopoulos nmav@gnutls.org writes:
I'd say to simplify to: chacha_crypt (20 rounds) chacha128_set_key (128 key bits) chacha256_set_key (256 key bits)
_chacha_crypt (arbitrary number of rounds)
Also makes sense to me. Do chacha users expect that "chacha" means 20 rounds, and not something more general?
In any case adding an algorithm which isn't used in any standard way is going to have the same issues (which options to add, how to name them etc.)
Agreed, we shouldn't spend much effort on non-standard variants. I'd just like to make sure if they're added, it doesn't make a total mess out of the nettle naming.
btw. why splitting the chacha_set_key() to chacha128_set_key() and chacha256_set_key() when the context is exactly the same?
Maybe I'm not totally rational about this.
But my thinking is that if the typical application does algorithm selection, including key size, at a higher level (e.g, using nettle_cipher or some similar application specific abstraction), it's useless to have another decision point inside the key setup function.
And in addition, for the algorithms that support a few discrete key sizes, often they are not simply parameterized by the key size, but they are different key setups, with different operations, or different magic constants, etc, and it simplifies the code to separate them.
That's why I'm leaning towards dropping the key size argument from nettle_set_key_func. It makes more sense to have a few wrapper functions where needed which assigns a constant value for the key size for those algorithms which truly are parameterized in key size. Than to have functions which just assert that the key size is the expected value, and then does the key setup for a fix key size.
A possible comprimize, for algorithms lika salsa20 and chacha which do use the same context for all key sizes, is to have all of
chacha128_set_key chacha256_set_key
and
chacha_set_key(..., size_t key_size) { switch (key_size) { default: abort (); case 16: chacha128_set_key(...); break; case 32: chacha256_set_key(...); break; } }
Maybe that's clutter, but I think the actual complexity cost is pretty low, so I don't think we have to be very afraid of it.
Regards, /Niels