On 01/16/2014 09:41 AM, Niels Möller wrote:
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?
The chacha paper uses the term chacha in place of salsa20 so I think it makes sense to use that term for the default with 20 rounds. In the end it makes no much difference as it's a matter of conventions in the library.
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.
It pretty much removes a switch, but I don't think that this is an important simplification. The important I see is the differences in memory usage by each variant but I'm not sure that's so significant either.
Nevertheless, you're right that nettle is now more consistent. I remember arguing before for set_key functions that take size and others that don't, so they couldn't be abstracted.
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 chacha_set_key(..., size_t key_size)
I think that would be convenient especially when the old API was like that, but in the end it adds even more functions so I don't know if it is good to have.
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.
The complexity as of in difficulty to use is pretty much the same (maybe an annoyance to the users of the previous API). However, now there are more functions to maintain.
regards, Nikos