nisse@lysator.liu.se (Niels Möller) writes:
- I'm not particular happy about the name SALSA20_CORE_INOUT_SIZE.
Just use SALSA20_BLOCK_SIZE. It's the same thing, right?
It is the same value at least. I'll use it.
- 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.
No, it is not a cryptographic hash function since it is not collision-resistant. Think of it as CRC or FNV.
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.
Right. I considered it, as a way to learn to assembler stuff in Nettle. However, I'm not sure there is a lot to gain, since there is no loop unrolling to speak off. But it could be considered.
+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.
Yes. I'm struggling with this aspect. The only canonical resource I have been able to find on the Salsa20 core function is this page:
It says clearly:
The Salsa20 core is a function from 64-byte strings to 64-byte strings: the Salsa20 core reads a 64-byte string x and produces a 64-byte string Salsa20(x).
and
The 64-byte input x to Salsa20 is viewed in little-endian form as 16 words x0, x1, x2, ..., x15 in {0,1,...,2^32-1}. ... producing, in little-endian form, the 64-byte output Salsa20(x).
So little endian and byte input/output is clearly intended.
The page goes on to show code that takes and return uint32_t and does no endian conversion. It says that this is the callers responsibility, so we can assume this is intended to be included in the definition.
However, the Salsa20 stream cipher seems to use the core function with uint32_t inputs, and scrypt does too. So perhaps we should expose a uint32_t->uint32_t interface as well that does no endian conversion. It seems scrypt doesn't little endian convert inputs but expects the output uint32_t to be little endian converted though... I'll bring this up with Colin.
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?
I've always regarded it as something intended for humans. I'm not sure what a compiler could do with the information. Perhaps it could be useful for optimizations though.
/Simon