On Wed, 15 Jan 2014 22:41:43 +0100 nisse@lysator.liu.se (Niels Möller) wrote:
Stefan Bühler nettle-bugs@stbuehler.de writes:
What about:
chacha20_crypt (20 rounds) chacha12_crypt (12 rounds) chacha_set_key128 (128 key bits) chacha_set_key256 (256 key bits) salsa20_set_key128 (128 key bits) salsa20_set_key256 (256 key bits)
My gut feeling is that think putting the number of bits last is too inconsistent with aes128_set_*_key and similar functions.
Imho that is the point; aes128_* are the functions of the AES128 variant, which "accidentally" uses a 128-bit key; the variant could have a different name (aes10 for 10 cycles), and would still take a 128-bit key. chacha_set_key128 is a function that works for all Chacha variants, and always takes a 128-bit key.
(I wouldn't split the key set functions for Salsa20 and Chacha in the first place - you didn't say why you wanted to split them, but you probably have your reasons)
Opinions?
Imho moving Salsa20/R functions to the ChachaR naming would work too :)
That's one option. What do others think? (We could keep aliases for backwards compatibility, whenever practical).
And don't forget XSalsa20/r (using HSalsa20/r and an additional 128-bit nonce, defined only for 256-bit keys afaik, but theoretically should work with 128-bit keys too)... xsalsa20r12_set_key256? :D
I'm not familier with those variants. But I think they should have a different name space (e.g., xsalsa*), so at least they shouldn't collide with plain salsa20 functions.
I just wanted to point out how riddiculous it looks when too many numbers are in a function name.
XSalsa basically replaces the Salsa20 key in set_iv with one derived (with HSalsa, selected output from the doublerounds) from the original key and additional nonce data as temporary iv and counter. So you would call "xsalsa20_set_iv" or "xsalsa20r12_set_iv" instead of "salsa20_set_iv", it wouldn't actually need a different set_key.