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