nisse@lysator.liu.se (Niels Möller) writes:
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)
There is no XOR in the Salsa20 core?
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.
Yes, the draft treat it that way because the function appears to be defined that way. The scrypt paper does too (http://www.tarsnap.com/scrypt/scrypt.pdf).
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.
I was mistaken, scrypt uses the uint32_t interface directly and (as epxected) without any endian conversion.
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.
No problem, I've made this change locally. Once we sort out the naming issue I'll submit another patch.
/Simon