nisse@lysator.liu.se (Niels Möller) writes:
Another alternative is to consider the function internal, at least for the time being, and name it _salsa20_core.
After some more thinking, I think this is the way to go. I'd like to propose the following plan:
* Do a _salsa20_core, working with uint32_t. Consider it an internal function, and keep the interface open (maybe it should be able to do several blocks, maybe it should byteswap output words, etc).
* Implement and document salsa20_core. It takes uint8_t blocks as input and output (together with key and round count), and calls _salsa20_core to do the work.
* Implement scrypt, in terms of _salsa20_core.
* Maybe have the C implementation salsa20_crypto also call _salsa20_core to do the main work. May require byteswapping in _salsa20_core output, to avoid a performance regression.
* Maybe do an x86_64 implementation of _salsa20_core (should be simpler than salsa20_crypt).
What do you think?
Regards, /Niels