(Imported from Google Code)
Certain parts of the password hash interface could have been named better.
The name of the
.encrypt() method has the implication that there might be a
.decrypt() that recovers the password. This is of course not the case.
One alternative name,
.encode(), suffers a similar problem. Another alternative,
.digest(), might be better... that name matches the similarly-purposed method used by the python hash interface (though the call syntax is different... would that cause confusion?)
In any case, this rename could be done, though it would have to have a very slow deprecation cycle.
The name of standard parameter
rounds reflects the unit of measurement, not the purpose: to adjust the time-cost of digesting a password. As well, it not technically correct for hashes which use a log2 cost parameter (eg bcrypt), as the actual number of iterations = 2**rounds.
Renaming it (and related informational attributes) to
cost would perhaps clarify things... though before doing so the nature of scrypt's multiple parameters should be studied to make sure a longer name such as
time_cost isn't required.
In any case, renaming this setting would be extremely disruptive and burdensome, particularly if the deprecation cycle was long (which it would need to be). So this will probably not be done any time soon (if ever).