Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.
Sign up to join this community
I have been examining the scrypt paper, and I noted the claims in table 1.
For 10 random ASCII characters, the cost at that time for scrypt set to $(2^{14}, 8, 1)$ is estimated to be $175T/yr.
Can formulae for equivalent year cost be constructed to determine the parameters as functions of time since those tests were performed?
Can formulae for equivalent year cost be constructed to determine the parameters as functions of time since those tests were performed?
Yes, but you have to make a lot of assumptions. First, though, note that the paper says:
We caution again that these values are very approximate [...] Nevertheless, we believe that the estimates presented here are useful for the purpose of comparing different key derivation functions.
The estimates are not necessarily very accurate as absolute values, but only in relation to each other. They are based on numbers from 2002.
That said, there are three parameters to tweak in scrypt: $N$, $r$ and $p$. Increasing $p$ increases only the computational cost. Increasing $r$ or $N$ also increases memory use. The effect of $p$ is easiest to estimate:
Doubling $p$ doubles the time taken per try, so the attacker needs twice as many devices to calculate the same number of hashes in a year, so the attack cost doubles.
Now how much cheaper has computing power become since 2002?
Conservatively, then, you could increase $p$ from 1 to e.g. 64 to account for the increased performance/\$ potential, but that would likely increase the time it takes significantly, at least unless your implementation is parallelized (for $p>1$ the different SMix invocations can be calculated in parallel).
Increasing $N$ would be even better, because of the increased memory use – not only would the attacker need twice as many devices, but each of those would be more expensive as well. However, the effect of that is more difficult to estimate. Additionally, that may not be doable in a low memory environment, like mobile or in the browser.
In practice, I think a better approach is to set a target time and find the highest numbers you can use and still make a target time.
