I've been trying to look for the answer, but the latest one I found was outdated by three years. So what are the recommended scrypt cost factors for 2016?
Asked
Active
Viewed 639 times
8
-
2The recommended cost factors = "Use Argon2"? – SEJPM Apr 29 '16 at 12:39
-
What? I'm not sure I understand what you're saying. – Awn Apr 29 '16 at 15:22
-
1Not sure if this'd be the correct thought process, but I'd think to use moore's law and assume that since 2^3 = 8, so at least 8x the 2013 estimates you found. – Cyrus Roshan May 11 '16 at 19:10
-
Moore's law is to do with transistors on a chip, not with the speed of computation. – Awn May 15 '16 at 12:19
1 Answers
7
In general, use the maximum cost factor that is bearable from a performance perspective. I would create a benchmark application which is as close as possible to what your application does, and find out the cost factor on your production hardware that gives you the maximum tolerable delay.
In most systems, I strive for a 10 to 20 ms delay. Assume your attacker has hardware that is, say, 1000 times more powerful than yours (which is not unreasonable, given that scrypt cannot be GPU-accelerated), he can try 105 guesses per second. For a 10-character alphanumeric password, that's 2610 passwords, or about 1014 potential guesses. That would take 109 seconds, or 31 years. Sounds acceptable to me.
If you want to use even higher delays, remember that scrypt is memory hard. This means it uses a (relative) lot of memory, in the order of megabytes, for each verification, so having a lot of them running in parallel might be more of a performance hit than the absolute processing power required.
Have a look at Security.stackexchange.com "Recommended # of iterations when using PKBDF2-SHA256?" for a good analysis of the same subject on PBKDF2.
Angelo van der Sijpt
- 243
- 1
- 7