Simon Josefsson simon@josefsson.org writes:
I realized that I didn't have any use for the round-reduced Salsa20 stream functions. So I'll focus on what I needed instead, which resulted in a much smaller patch. What do you think?
Looks reasonable to me.
Open issues:
- I'm not particular happy about the name SALSA20_CORE_INOUT_SIZE.
Just use SALSA20_BLOCK_SIZE. It's the same thing, right?
- Where could this be documented in the manual? "Miscellaneous functions"? We could also create a new section "Non-cryptographic Hash functions".
I think it would make sense to put it in the salsa section, possibly with a reference from the section on hash functions and any other place where it may be relevant. As I understand it, it *is* like a cryptographic function, but with a fixed input size.
What about assembly implementation? Do you think that is desirable? I think it should be fairly easy. Start with x86_64/salsa20-crypt.asm, move the QROUND macro to some other file (and maybe define some additional macros for shared code). And write a new salsa20-core.asm, which can be pretty simple, in particular, it doesn't need the complex code for handling partial blocks.
+void +salsa20_core (unsigned rounds,
uint8_t dst[SALSA20_CORE_INOUT_SIZE],const uint8_t src[SALSA20_CORE_INOUT_SIZE])
You settled on uint8_t input, rather than uint32_t? IIRC, the corresponding function in the salsa20 paper is defined with uint32_t array as input and an uint8_t array as output.
I guess little endian byte order of the input (matching the byte order for the output) is the only sensible choice? This ought to be clearly documented somewhere.
In nettle I currently don't use array types for function arguments. If you write them as arrays, like you do here, do current compilers make any use that for bounds checking, or do you just think it's clearer for humans?
Regards, /Niels