Hacker News new | past | comments | ask | show | jobs | submit login

@cperciva, slightly off-topic: I had a curious question this past week about one aspect of the scrypt algorithm. If I recall correctly, it sandwiches the memory hard function between PBKDF2, and uses Salsa20 as the mixing function internally. In the spirit of reducing code, I'm wondering if it makes sense to replace Salsa20 with HMAC, SHA256, or just SHA256's mixing function? It would reduce the number of crypto primitives in the implementation. Not that it really matters much, but just curious (and partially curious if Salsa20 had specific properties that are useful in scrypt's design). Sorry if this is a dumb question; I was going to read back through your scrypt paper, but have been busy all week.

Salsa20 could be replaced by almost anything -- the requirements for the mixing function are very very weak (basically just that there's no short-cut to iterating). But Salsa20 has an advantage in throughput, which matters for maximizing the amount of memory you can use in a given amount of time.

Asymptotically speaking the best function there is the one which maximizes [B/s software output]^2 / [B/s hardware output].

Can you elaborate a little on how you got to that maximization? I am not sure I understand why you're squaring the software level.

ASIC cost ~ memory * time = (time_software * bandwidth_software) * (time_software * (bandwidth_software/bandwidth_hardware)) = (time_software)^2 * (bandwidth_software)^2 / bandwidth_hardware.

Thank you for reply. Then I suppose re-using the SHA2 primitive doesn't make much sense, except perhaps in awkwardly constrained environments (area starved ASIC/FPGA, embedded processor with accelerated SHA, etc). Regardless, it's interesting to know that the mixing function can be swapped around.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact