ni...@lysator.liu.se (Niels Möller) writes: > Simon Josefsson <si...@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 _______________________________________________ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
