Simon Josefsson simon@josefsson.org writes:
No, it is not a cryptographic hash function since it is not collision-resistant. Think of it as CRC or FNV.
I'd like to understand better the properties of Salsa. As I see it, we have a complicated non-linear, but easily invertible, permutation on blocks of 64 bytes (or 512 bits). Call this function P(X). Then we construct a hash function
F(X) = X xor P(X)
The XOR is intended to destroy invertibility both in theory (it's no longer a one-to-one map, or a permutation) and practice (given F(X), it's hard to find a preimage). Am I right so far, or is there some working trick or attack which finds a preimage?
But then I have no idea on the number and structure of the collisions, and on the difficulty of finding a pair of colliding inputs X != Y, F(X) = F(Y).
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.
For salsa20 and x86_64, the main gain comes from using sse2 instructions to exploit the parallelism in the QROUND function.
However, the Salsa20 stream cipher seems to use the core function with uint32_t inputs,
Well, it does use little endian explicitly, when copying key material into the salsa core input.
and scrypt does too.
Reading the internet draft, it looks like it treats input and output as 64 bytes. I haven't read any other scrypt materials.
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.
Please do, this needs to be sorted out.
In nettle I currently don't use array types for function arguments.
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.
I tend to use pointer notation, because (1) it's what really happens, (2) it's shorter to write, and (3) because arrays may give a casual reader the impression that something more complicated happens. Neither is a very good reason, but for now I think we should stick to pointers for consistency within Nettle. If arrays notation is better, we should change that in all places where we pass arrays of constant size.
Regards, /Niels