3 ms·
https://github.com/Tarsnap/scrypt https://github.com/Tarsnap/scrypt Side note, I've seen a number of places (including the Scrypt repo) compare bcrypt brute-fo
by cj 6y ago
https://github.com/Tarsnap/scrypt https://github.com/Tarsnap/scrypt
Side note, I've seen a number of places (including the Scrypt repo) compare bcrypt brute-force benchmarks without specifying the bcrypt work factor.
It's very frustrating to see this, considering the time to compute a single bcrypt hash can be < 0.01 seconds (ie. work factor 7 or 8), or more than 1 minute (ie. work factor 20).
I'm not familiar with scrypt, but it looks like instead of providing a work factor, you can provide inputs like "max time to compute hash" and "max percent of ram to use computing hash" which presumably scales up as hardware becomes more powerful?
- cperciva 6y agoI've seen a number of places (including the Scrypt repo) compare bcrypt brute-force benchmarks without specifying the bcrypt work factor. It's specified implicitly in the scrypt README file: "if 5 seconds are spent computing a derived key". It's explicit in the conference paper (cost = 16).
- gperciva 6y agoThe algorithm itself takes three cost&memory values N, r, p, and if you're calling the `crypto_scrypt()` function in C or C++ as a KDF you need to specify those. The command-line binary generally takes "max time" and "max ram" (as percent and/or raw value) and estimates appropriate cost values. As of version 1.3.1, you can manually specify cost values for the binary if you want.