3 ms·
@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 memor
by fpgaminer 13y ago
@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.
- cperciva 13y agoSalsa20 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].
- gburt 13y agoCan you elaborate a little on how you got to that maximization? I am not sure I understand why you're squaring the software level.
- cperciva 13y agoASIC cost ~ memory * time = (time_software * bandwidth_software) * (time_software * (bandwidth_software/bandwidth_hardware)) = (time_software)^2 * (bandwidth_software)^2 / bandwidth_hardware.
- fpgaminer 13y agoThank 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.