nisse@lysator.liu.se (Niels Möller) writes:
Simon Josefsson simon@josefsson.org writes:
I'll proceed cleaning up the Salsa code next, to reach my goal of having scrypt in here as well (I have it working on https://www.gitorious.org/scrypt/nettle-scrypt).
That's the algorihtm described in https://tools.ietf.org/html/draft-josefsson-scrypt-kdf-00, right?
Yes.
What features do you need for the salsa interface? After a quick look, it seems you will not be processing independent blocks with salsa20, so you will not be able to take any advantage of parallelism there (which I imagine is an intended feature of scrypt).
Right. See the patch in the last e-mail for the feature I need.
It's straight forward to add a round parameter to salsa20. But it's still not clear to me what's the best way to support hashing only. It would have been a bit easier if you could replace
X = Salsa(X xor B[i])
by
X = Salsa(X) xor B[i]
since the latter is closer to the standard encryption operation. I think the iteration *can* be rewritten in that form by some change of variables, but you'd need an extra xor at the end to really get Y[i] rather than Y[i] xor B[i]. The algorithm specification is already set in stone?
Setting it stone is my goal. Scrypt has been in use for around 3 years and is implemented in several languages. Admittedly, several people (including myself) have ideas about various tweaks to the algorithm that may improve it, but I believe it is better for those ideas to be described separately under a different name. It would be extremely confusing for "scrypt" to mean anything but the algorithm described in the original paper.
/Simon