nisse@lysator.liu.se (Niels Möller) writes:
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).
Should that function really be declared in salsa20.h then?
- 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.
I assume you didn't mean key here, since it is unkeyed.
- Implement scrypt, in terms of _salsa20_core.
Works for me.
- 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.
Yes, this approach was used in an earlier patch.
- Maybe do an x86_64 implementation of _salsa20_core (should be simpler than salsa20_crypt).
Benchmarking it first might be good, I'm not sure you actually gain a lot here since there is no chained block operation like stream ciphers on bigger buffers.
I won't be able to do any more work on this until Monday though. I think we are essentially done though, so feel free to push things according to the plan above. Or I can put together something next week.
Thanks, /Simon