nisse@lysator.liu.se (Niels Möller) writes:
Simon Josefsson simon@josefsson.org writes:
+void +salsa20_core (uint8_t *dst,
const uint8_t *src,unsigned rounds)is not ideal -- the reason is that the Salsa20 core is not defined with a parametrised number of rounds, so the interface is somewhat of a bastardisation.
Naming is difficult, it's awkward to use the prefix "salsa20" for a function which is "salsa20, but not really 20"... In sed syntax it would be salsa20_sx20xrx ;-)
It could be argued that the name of the function is actually "Salsa20 core" and that reduced round versions would be "Salsa20/r core" or similar. That would be consistent with the naming scheme for the Salsa20 stream cipher -- there Salsa20/12 means the Salsa20 stream cipher but with 12 rounds. It is not called Salsa12.
In my work space, I have used the namespace 'salsa20r_core' instead. This opens up for later addition of a true 'salsa20_core' function which would use the official 20 rounds.
What do you think?
I have no better suggestions for naming. But if we think of salsa20r_core as mostly for internal use, maybe we don't need it?
If I understood you correctly, your primary use case is scrypt, which you intend to implement in Nettle? Then maybe you would be better off without an extra wrapper function around _salsa20_core? If nothing else, you could then make sure you have proper alignment so you don't need an extra memcpy.
I hesitate a bit to add, document and support a new "obscure" function until there's a clear external use case.
Good points. Generally, I think it would be nice to have public interfaces for the Salsa20 core function, but currently there really aren't any use-cases for it except for scrypt that I am aware of. The conservative approach then is to not expose it right now.
What is driving this particular patch, though, is that the scrypt code needs a salsa20 core function that takes uint8_t's and return uint8_t's. I think there are two ways to address that need:
1) Implement the salsa20r_core uint8_t function in the scrypt file.
2) Add another internal function in salsa20.h that implement the uint8_t interface.
I prefer the second alternative, because then the implementation is done in the right place if there is ever another need for the salsa20 core uint8_t interface within Nettle (or externally). Thoughts?
I'm thinking it could be something like:
void _salsa20_core8(uint8_t *dst, const uint8_t *src, unsigned rounds);
possibly the current _salsa20_core should be renamed _salsa20_core32 for consistency. Having the uint32_t interface be called _salsa20_core even if it is an internal function seems a bit confusing -- the proper interface to it is uint8_t's.
/Simon