Simon Josefsson simon@josefsson.org writes:
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.
I think the name "salsa20r_core" is good enough. If we ever do some function(s) specifically for 12 rounds, what would they be called? salsa20r12_*? Make some sense to me.
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:
Implement the salsa20r_core uint8_t function in the scrypt file.
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 think I prefer 1) for now. At this point, I don't want to rule out the possibility that it turns out to be preferable to adapt the scrypt code to call the more awkward _salsa20_core directly (if we can avoid a memcpy, it may even give a modest performance improvement).
And it's easy to move salsa20r_core to a separate file and make it non-static later on, whenever the need arises.
I'm thinking it could be something like:
void _salsa20_core8(uint8_t *dst, const uint8_t *src, unsigned rounds);
I see no reason to use a different name than salsa20r_core, as you suggested above. In nettle, leading underscore names are mainly for functions with awkward interfaces, dictated by what's suitable for assembly implementation or other implementation specific issues, and where it is likely that the interface will change as the implementation evolves. And the salsa20 core function you want is not of that character, whether documented or not.
Regards, /Niels