It seems paradoxical that decompressing data on the fly could be faster than reading it directly. However, modern CPUs possess highly optimized decompression routines (e.g., Intel’s QAT, or software like zlib-ng) that can decompress at speeds exceeding 1 GB/s. Meanwhile, storage I/O, particularly for random reads or rotational media, struggles to reach 100–200 MB/s. By storing the wordlist in a compressed form, the system trades cheap CPU cycles (decompression) for expensive disk I/O (reading fewer bytes). Empirical benchmarks with Hashcat show that a 20 GB uncompressed wordlist compressed to 3 GB (e.g., using gzip -9) can reduce total cracking time by 30–50% on a standard SSD, and by over 70% on a hard disk drive. The GPU remains fed, and the CPU core handling the wordlist reader stays busy decompressing rather than waiting on the storage controller.
for wl in *.zst; do if [[ -f "$wl" ]]; then echo "[+] Streaming $wl via Zstd" zstdcat "$wl" | hashcat -a 0 -m $MODE $HASH -O -w 4 -r best64.rule fi done hashcat compressed wordlist
for wl in *.gz; do if [[ -f "$wl" ]]; then echo "[+] Streaming $wl via Gzip" gunzip -c "$wl" | hashcat -a 0 -m $MODE $HASH -O -w 3 - fi done It seems paradoxical that decompressing data on the
zcat rockyou.txt.gz | hashcat -m 0 -a 0 hashes.txt
For professional password auditors, here is the ideal directory structure: zcat rockyou
/opt/wordlists/
├── rockyou.txt.gz
├── SecLists/Passwords/xato-net-10-million-passwords-1000000.txt.xz
├── custom/
│ ├── breached_2024.zst
│ └── mutations.zst
└── scripts/
└── crack_with_compressed.sh
Hashcat cannot natively read compressed files (.gz, .bz2, .xz), but you can pipe the decompressed output directly into hashcat without extracting the file to disk.
bzcat wordlist.bz2 | hashcat -m 0 -a 0 hash.txt