What are optimal scrypt work factors?
I'm using a Java scrypt library for password storage. It calls for an N, r and p value when I encrypt things, which its documentation refers to as "CPU cost", "memory cost" and "parallelization cost" parameters. Only problem is, I don't actually know what they specifically mean, or what good values would be for them; perhaps they correspond somehow to the -t, -m and -M switches on Colin Percival's original app?
Does anyone have any suggestions for this? The library itself lists N = 16384, r = 8 and p = 1, but I don't know if this is strong or weak or what.
Answer
As a start:
cpercival mentioned in his slides from 2009 something around
- (N = 2^14, r = 8, p = 1) for < 100ms (interactive use), and
- (N = 2^20, r = 8, p = 1) for < 5s (sensitive storage).
These values happen to be good enough for general use (password-db for some WebApp) even today (2012-09). Of course, specifics depend on the application.
Also, those values (mostly) mean:
N: General work factor, iteration count.r: blocksize in use for underlying hash; fine-tunes the relative memory-cost.p: parallelization factor; fine-tunes the relative cpu-cost.
r and p are meant to accommodate for the potential issue that CPU speed and memory size and bandwidth do not increase as anticipated. Should CPU performance increase faster, you increase p, should instead a breakthrough in memory technology provide an order of magnitude improvement, you increase r. And N is there to keep up with the general doubling of performance per some timespan.
Important: All values change the result. (Updated:) This is the reason why all scrypt parameters are stored in the result string.