nisse@lysator.liu.se (Niels Möller) writes:
I edited it a bit, to take out support for rounds != 20 for now (except for the _chacha_core_internal function), and I split the set key function into two functions for the two available key sizes, 128 and 256 bits.
I have a couple of questinos related to chacha naming.
With salsa20, the convention seems to be that "salsa20" is the name of a family of ciphers, with the main instantiation having 20 rounds, and variants with names like "salsa20_r12" or "salsa20/12". Which is a bit clumsy. And then, each round has two possible key sizes.
In the chacha paper I've read, it seems that "chacha" is the name of the family, and "chacha20" always refers to the 20-round variant. So a reduced round chacha would be named "chacha12", not "chacha20_r12". Right?
Should we follow that naming? If so, the 20-round crypt function should be "chacha20_crypt" (not "chacha_crypt"), and if we introduce a crypt function with a variable number of rounds, that could be named "chacha_crypt".
It might be a bit confusing if we have
chacha20_crypt (20 rounds) chacha12_crypt (12 rounds) chacha128_set_key (128 key bits) chacha256_set_key (256 key bits)
But since the number of rounds is irrelevant to key setup, and key size is irrelevant to the crypt function, there's logic and method in that apparent madness. One could have a different name (or alias) chacha20_128_set_key, but that's clumsy, and I don't think it would reduce confusion.
if I split the key setup also for salsa20 into two functions for the two different keysizes, it would make some sense to me to call then salsa128_set_key and salsa256_set_key (rather than the clumsier salsa20_128_set_key and salsa20_256_set_key). But I'm not sure which is most important, consistency with corresponding chacha functions, or consistency with salsa20 conventions outside of nettle.
In either case, the current salsa20_set_key (with a key size argument) should be kept for backwards compatibility.
Opinions?
Regards, /Niels