I actually liked to format personally. As I am on mobile I prefer the scrolling action over having to click buttons to goto the next page of a slide.
I remember using john the ripper and hashcat back in the day to see how secure my old passwords are....and boy has the technology really come along way
Is there any good data out there about the cracking speeds against argon2? I was disappointed that I didn't see that mentioned along with the other memory-hard algorithms, good data on that seems to be really hard to find.
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.
