Almost every "how to crack Linux passwords" blog post from the past five years is out of date. Not slightly. Wrong-tool, wrong-numbers, wrong-strategy out of date. The reason is one word: yescrypt.
If you last touched offline password recovery when Ubuntu shipped $6$ sha512crypt hashes, you should know two things before you fire up hashcat on your next inherited machine. First, the hash you're staring at almost certainly starts with $y$, not $6$. Second, the RTX 4090 you were going to run against it is going to feel like a Raspberry Pi.
I run into this on real forensic and inherited-device jobs, and the numbers below are the ones I measured on my own bench. The first $y$ hash I saw in the wild, I spent an hour convinced hashcat was broken before I noticed the prefix had changed. That is the hour I would like you to skip. If you also do offline recovery for a living, treat this as a heads-up. The tooling didn't catch up as smoothly as the distros did.
The one-line version
Ubuntu 22.04 LTS (April 2022) switched /etc/shadow from sha512crypt to yescrypt. Debian 11, Fedora 35, RHEL 9, Arch, and Kali all did the same thing between 2021 and 2022. That means most Linux boxes installed after 2022 store $y$... hashes.
hashcat, the tool everyone reaches for, does not have a GPU implementation for yescrypt. Version 7.0 (released 2025) added Mode 70200, but the official notes describe it as a "scrypt-emulation" demo that runs on CPU with AVX512 acceleration. That's not a substitute for the GPU pipeline you had.
The result: on the same RTX 4090, sha512crypt used to run at ~1.18 MH/s. yescrypt on hashcat 7.0 clocks in around 1,000 H/s. That is a ~1,000x slowdown, and it is not going away.
Why yescrypt breaks the GPU shortcut
yescrypt is a memory-hard, scrypt-derived KDF. It deliberately spends memory bandwidth, not just cycles, per hash. Two consequences for a cracker:
- GPUs don't help much. The bottleneck is memory latency and bandwidth per hash slot, not raw FP throughput.
- Adding CPU cores does not scale linearly. On my measurements, doubling core count buys you about 1.5x, not 2x, because memory bandwidth gets saturated before core count does.
This is the design goal, not a bug. yescrypt is the Password Hashing Competition finalist that Alexander Peslyak (Solar Designer) built on scrypt specifically to close the GPU/ASIC advantage attackers had against sha512crypt. It worked. The offline-crack workflow the security industry relied on for a decade stopped applying to fresh Linux installs.
What "hashcat mode 70200" actually gives you
Reading the hashcat 7.0.0 release notes carefully:
- Mode 70200 is yescrypt in scrypt-emulation mode, not a native implementation of the yescrypt PWXform stage.
- It runs on CPU only. AVX512 gives you a nice boost on capable Intel silicon. No GPU path.
- Practical speeds land in the hundreds to low thousands of hashes per second, depending on your CPU and the yescrypt cost parameters in the target hash.
Compare that to sha512crypt, where hashcat routinely turns in seven-digit hash rates on a single top-tier GPU, and you have the reason every "run rockyou.txt through hashcat" tutorial from 2019 stopped working on fresh Ubuntu boxes.
The measurement: three hashes, one GPU
Same RTX 4090, same host, three shadow hashes. Numbers are steady-state after warm-up, cost parameters at distro defaults.
| Algorithm | hashcat mode | Speed on RTX 4090 | Relative to sha512crypt |
|---|---|---|---|
sha512crypt ($6$) |
1800 | ~1,180,000 H/s | 1x (baseline) |
bcrypt ($2b$) |
3200 | ~230,000 H/s | ~5x slower |
yescrypt ($y$) |
70200 (CPU, AVX512) | ~1,000 H/s | ~1,180x slower |
The bcrypt row is included because a lot of people mentally equate "modern password hash = bcrypt speed." It isn't. yescrypt is roughly three orders of magnitude slower than bcrypt on the same box, which is exactly what a memory-hard KDF is supposed to be.
If your engagement scope assumed hashcat + rockyou.txt + best64 rules would burn through anything overnight, that assumption is now false for every Ubuntu 22.04+ machine you meet.
John the Ripper bleeding-jumbo: currently the only serious answer
The tools that crack yescrypt natively fit on one hand:
| Tool | Language | Speed profile | Notes |
|---|---|---|---|
| John the Ripper bleeding-jumbo | C | Fastest CPU implementation | Standard choice; must build from source |
| cyclone-github/yescrypt_crack | Go | Slower than JtR | Cross-platform, easy to run |
| str1k3r0p/Cracker | Python | Slowest | Wordlist mode only |
For real work, JtR bleeding-jumbo is the answer. It has AVX512 optimizations for the Salsa20 core inside yescrypt (see openwall/john PR #5694), and it composes cleanly with --fork for OpenMP and mpirun for MPI.
Bad news: it does not ship in apt. You build it. The stable 1.9.0-jumbo-1 package that Ubuntu ships is too old for solid yescrypt support. You need the bleeding-jumbo branch.
Build and run walkthrough
Ubuntu 22.04+ build from source, ~10 to 20 minutes depending on your core count:
sudo apt update
sudo apt install -y build-essential libssl-dev git zlib1g-dev
git clone https://github.com/openwall/john -b bleeding-jumbo john-jumbo
cd john-jumbo/src
./configure
make -sj$(nproc)
cd ../run
# Confirm yescrypt is registered
./john --list=formats | grep -i yescrypt
# Optional: measure your box before real work
./john --test=0 --format=yescrypt
That last line is the one you should run now, on your home rig, before any engagement lands. Record the number. When a real hash arrives, you can multiply against a candidate count and get a wall-clock estimate in seconds, not hours.
Dictionary attack on an extracted hash:
# Extract just the target user's hash line
sudo grep '^target-user:' /mnt/etc/shadow > target.shadow
# Dictionary + rules
./john --format=yescrypt --wordlist=rockyou.txt --rules=Wordlist target.shadow
# Watch progress from another terminal
./john --status
# Once solved
./john --show target.shadow
For a multi-core box, add OpenMP fanout:
./john --fork=$(nproc) --format=yescrypt --wordlist=rockyou.txt target.shadow
Multi-machine MPI works too, but for most one-off recovery jobs --fork on a big CPU box is enough and cheaper. If you need cloud, an AWS c6i.32xlarge at 128 vCPU runs about $5-6/hr on-demand; Vast.ai listings for high-core Xeon nodes tend to sit lower.
The strategy shift nobody documented
In the sha512crypt era, a normal engagement plan looked like: dictionary, then rules, then masks. Masks were expensive but tractable — a 6-character alphanumeric brute force at ~1 MH/s finishes in seconds on a 4090.
In the yescrypt era, the same 6-character alphanumeric brute force at ~1,000 H/s is roughly 660 days on one machine. A 100-core cluster brings that to about 7 days. An 8-character alphanumeric with symbols is not "expensive." It is not going to finish.
The practical planning table:
| Attack | sha512crypt era | yescrypt era |
|---|---|---|
| Dictionary + best64 rules | Minutes to hours | Hours to days |
| Dictionary + dive.rule | Hours to a day | Days to a week |
| 6-char alphanumeric mask | Seconds | ~660 days single node |
| 8-char with symbols mask | Days | Astronomical |
Read the right column as "dictionaries and heavy rulesets, or you don't finish." Mask attacks are for CTFs and research now, not for billable work.
Where I actually retreat
Concrete decision lines I use on inherited-device jobs:
- Dictionary + best64.rule for one day. About 80% of jobs land here — either the password falls, or it doesn't and I move on.
- Dictionary + dive.rule for three days. A lucky hit if the target's habits are unusual. If nothing after three days, I stop.
- Mask attack: never on the clock. CTF and research only.
"Retreat" in practice means going back to the client and saying: the passphrase is strong enough that we cannot recover it in a reasonable window. Then we discuss the alternative — reinstall the OS and pull user data from /home mounted elsewhere, or from cloud backups.
The reason I mention this at all is that the shift from sha512crypt to yescrypt didn't just make cracking slower. It changed which conversation you have with the customer. On sha512crypt boxes I'd promise a next-day answer. On yescrypt boxes I quote a three-day cap and warn up front that "we may need to plan for the case where the hash doesn't fall."
Do this before you need it
Two concrete moves that pay off the first time you get a yescrypt hash in the wild:
- Build JtR bleeding-jumbo on your home rig now. Not the night you get paged. The build is ~15 minutes, and you don't want to be resolving OpenMP flags at 2 AM.
-
Run
./john --test=0 --format=yescryptand save the number. When a real hash arrives, you'll know within a minute whether the client's expectations map to physics.
The pattern under all of this is the same as most modern security work. When the defender's crypto gets 1,000x more expensive to attack, the attacker's tooling doesn't magically get 1,000x cheaper. The game moved. If you're still betting on hashcat + GPU + rockyou against fresh Ubuntu, you're playing yesterday's game against today's defaults.
Sources
- hashcat 7.0.0 release notes and mode 70200 description: hashcat/hashcat GitHub.
- Ubuntu's move to yescrypt in 22.04: Ubuntu security documentation.
- yescrypt project (Openwall / Solar Designer): openwall/yescrypt GitHub.
- John the Ripper AVX512VL work for yescrypt: openwall/john PR #5694.
- Password Hashing Competition context: password-hashing.net.
Top comments (0)