Nikos Mavrogiannopoulos <[email protected]> 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
--
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