Simon Josefsson <[email protected]> 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 -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
