Linux Kernel Runtime Guard (LKRG) is a Linux kernel module that performs runtime integrity checking of the kernel and detection of security vulnerability exploits against the kernel, prevention of and response to successful attacks, and encrypted remote logging. Direct link is to recent talk slides, but please also click through to the project website https://lkrg.org from there.
There's not much data on these yet, in part because optimized GPU implementations were lacking. We just got one for Argon2 (based on a third-party project, but we optimized it further) into John the Ripper half a year ago, and a benchmark of it is included on slide 42 https://www.openwall.com/presentations/OffensiveCon2024-Pass... albeit that's using somewhat dated hardware. In my experiments, Argon2's break-even point for CPU vs. GPU (where GPUs stop being faster) is at 100+ MB (likely even higher with newer GPUs), which is pretty high and inconvenient for some defensive uses. The issue is Argon2's excessive parallelism - on that slide, you can see that we're able to do 15k concurrent computations (filling pipelines of 2.5k x 32-bit "CUDA cores") when we compute only 480 Argon2 hashes concurrently.
For scrypt, you can see hashcat speeds (not in these slides), but I think there's room for further optimization.
For yescrypt, there's no GPU implementation yet, but there are of a non-final algorithm as reused by some cryptocurrencies (launched before yescrypt 1.0), so we can extrapolate from there (the final thing is moderately more GPU-unfriendly), like I tried here: https://lists.openwall.net/phc-discussions/2018/04/29/1
We ought to implement yescrypt on GPU as well, even if just to show how much better it fares against the competition. ;-)
As to CPU implementations, they're currently similar speed for defense and offense, except that in password cracking it's easier to move memory (de)allocation out of the loop, for a ~40% speedup or so - or less if the hash is configured to use multiple iterations over memory, thereby amortizing the (de)allocation cost, but then its memory hardness is suboptimal (could instead have used more memory in this time). Larger defensive deployments (such as dedicated password hashing servers/clusters we've consulted on setting up) also have this overhead out of the loop, but typical libraries and apps don't.
(I'm not happy with how Jeremy re-purposed the words "blind hashing" to mean essentially the approach I had recommended as a better alternative to his original "blind hashing", which I criticized in the ZeroNights talk, but other than that I agree with what he wrote.)
To "make it harder to parallelize assuming attacker does get the file" (actually, to increase the cost per candidate password tested, not to make anything literally "hard to do"), I propose that "best of both worlds" approach (see my ZeroNights slides). And you're right, this means "designing an entire password hash, not just a friendly wrapper" (thus, different from Jeremy's work, and more similar to my work on yescrypt).
"Hash upgrades" have been added with the just-published v1 of the yescrypt submission to PHC. There is not yet an implementation of an "upgrade this hash" function (also, hash encoding needs to be finalized, including encoding of the upgrade count parameter), but now it's a matter of writing this additional code outside of the actual password hashing code (already capable of computing possibly-upgraded hashes).
Unfortunately, with memory-hard schemes such upgrades involve an efficiency loss in terms of normalized area-time, and there's a tradeoff between granularity of upgrades and efficiency. For Catena (another PHC finalist that supports these), the time granularity is 2x to 3x, with efficiency down to 33.3%+ of non-upgraded hashes (after many upgrades). For yescrypt, it's 4x to 5x granularity and 60%+ efficiency, respectively. (I felt that 33.3%+ is just not good enough - in my opinion, it's usually better to postpone the upgrade until 60%+ can be achieved rather than upgrade early and prevent it from ever being achieved. The next easy step would be 77.7%+, but the granularity would be too high.)
At the same time, support for ROM access frequency tuning (and thus for ROM-on-SSD, as opposed to ROM-in-RAM) has been dropped from yescrypt for now. The rationale is that builtin ROM-on-SSD didn't make enough sense without also having a ROM-in-RAM (in use cases for the former, the latter would also be easily affordable, including complexity wise, and would provide significant extra defense), and supporting two ROMs at once would be further beyond the comfort level for complexity of a hashing scheme in PHC (yescrypt is already somewhat beyond the comfort level). Support for two ROMs along with access frequency tuning might be re-added in an extended revision of yescrypt for specialized use cases at a later time, but this will be outside of PHC.
Differently! The goal of PHC is to improve upon the current state-of-the-art, which includes bcrypt and scrypt, but there are many tradeoffs involved. A scheme that is better in one aspect might be worse (or just different) in another.
These finalists try to improve upon scrypt (increase attack/defense cost ratio or/and avoid cache-timing side-channels while building upon ideas from scrypt and more): Argon, Catena, Lyra2, yescrypt, and maybe POMELO. Ditto for some non-finalists: Gambit, RIG, TwoCats. (Arguably some other non-finalists fall in this category as well.)
These finalists include bcrypt-like components or properties while being scalable (to a varying extent) to larger than bcrypt's memory usage: battcrypt, POMELO, Pufferfish, yescrypt. And a non-finalist: TwoCats. Unlike bcrypt itself, battcrypt is likely to be implementable in scripting languages that offer native Blowfish.
These finalists are totally different from bcrypt and scrypt, not trying to improve upon them nor even be on par with them: Makwa and Parallel. They are for different applications than bcrypt and scrypt. Parallel can be said to try to improve upon PBKDF2, though.
As to more specific comparisons, with benchmarks and cost estimates for various settings on various types of hardware, this goes beyond a comment reply like this (or I'd need to focus on one PHC candidate, like mine, which would be unfair). It is a topic for the PHC discussions list and for materials included with each PHC candidate (some do include various numbers or/and claims to this extent).
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.
