| Slow to the extent affordable (thus, must be tunable) yet highly efficient on defender's hardware is best. (warbiscuit is correct on this.) "Hard" is a wrong word to use - we're not trying to make things hard to do (as this would only increase the initial investment needed for attacks), we're trying to increase the attackers' cost per candidate password tested. "Rainbow tables" are made irrelevant by proper use of salts. It's kindergarten stuff, as far as PHC is concerned. "Too slow for its memory usage" refers to some of the schemes that claim to be (and possibly are) memory-hard (see the scrypt paper). For those, it is desirable to be able to tune them such that their memory usage is maximized for a given running time or hashes per second throughput. For example, a scheme that can be tuned to achieve 1000 hashes/s at 16 MB memory usage per hash computed might win competition over a scheme that only achieves at most 10 hashes/s at the same memory usage on the same server. The latter happens not to be usable for password authentication on a server at that memory cost setting. Of course, there are also applications where the absolute maximum memory usage is not desirable - e.g., 1 second of running time might be affordable for deriving an encrypted filesystem key, but only e.g. 256 MB of free RAM might be available on a mobile device. There are PHC finalists that can be tuned to limit their memory usage as well, even if tuned to run for a long time, or that don't use much memory at all. Disclosure: I am the submitter of yescrypt. I also participate on the PHC panel (non-voting, because of having my own submission), along with many others. |