[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CAF37FbXujqFdp4NzZu2S0S7p88eKRDJDn7zoyezmHdrNgPST6A@mail.gmail.com>
Date: Fri, 23 Oct 2026 07:01:16 +0200
From: atom <atom@...hcat.net>
To: john-users@...ts.openwall.com
Subject: hashcat: FPGA support built on JtR's bcrypt work, and John's dynamic formats
Hey all,
two changes that have landed on hashcat master may interest this list.
Both are on master only for now and will be part of the hashcat v8.0.0
release soon.
https://github.com/hashcat/hashcat/commit/ae9a19f
1. FPGA bcrypt support, built on JtR's bcrypt work
hashcat now supports FPGA boards for cracking bcrypt. This work builds
on JtR's FPGA support. Here is what hashcat contains:
- bcrypt only. JtR's other FPGA designs are not included.
- For the ZTEX 1.15y, hashcat loads JtR's prebuilt bcrypt bitstream and
the inouttraffic firmware, both redistributed unchanged. Building a
new bitstream for the board's Spartan-6 requires Xilinx ISE, which
we do not have. The bitstream therefore does not include any of the
changes below. hashcat's host code for that board is a port of JtR's
ZTEX host code and packet protocol.
- Denis Burykin's bcrypt core is also the compute core in hashcat's own
designs for six more boards: the YPCB-00338-1P1, the Xilinx ZC706, the
Enigma X1, the Alveo U50, the ZTEX 2.13 and the Digilent Arty Z7-20.
src/fpga/bcrypt/PROVENANCE.md lists every change made to his files.
docs/credits.txt credits him, Solar Designer, the JtR project and
ZTEX GmbH.
- Both 1.15y files are licensed under the GPL: version 3 for the
firmware and version 2 or later for the bitstream. We therefore
publish their source alongside them on hashcat.net: JtR's
src/ztex/fpga-bcrypt from the commit used to build the bitstream,
and the inouttraffic firmware source.
hashcat's own designs change a few things around the core and inside
it. Some of this may also be useful for JtR's designs:
- In JtR's design, the arbiter reads each core's full result before
the comparator checks for a match. Where the board has room,
hashcat's designs give each core its own result filter instead:
a bitmap of 128 bits indexed by the low bits of the first digest
word of the loaded hashes. Each filter drains its own core as soon
as a result is ready. Results that cannot be cracks are reported
in about 6 cycles, so only possible hits go through the serial
readout. A hit still goes to the host, which compares the full
digest. The filter is in hcfpga_result_filter.v.
- The host mixes candidates with known answers into the batches and
checks their digests. This detects cores that keep running but
produce incorrect digests. Each result frame identifies the core
that produced the result.
- The core itself now has an input bus 32 bits wide. Each core can use
block RAM or LUTs for its S-boxes, so an array can use both resource
pools. There is also a fix for a reset problem. Resetting a core in
the middle of a job previously left its PD write pointer unchanged,
causing the next data batch to be written in the wrong place.
MC[0] now loads that pointer. Normal operation is unchanged.
PROVENANCE.md describes these changes.
- For the YPCB, we derived a variant that runs two hashes per core.
Both hashes share one physical core running at twice the fabric
clock frequency. Their state fits in the half of each S-box block
RAM left unused by the original core. On the YPCB, this gives
760 virtual cores at 115 MHz. The change is in bcrypt_core_c2.v.
If JtR incorporates any of these changes into its 1.15y design,
hashcat users with that board would also benefit, since hashcat loads
JtR's bitstream. The packet protocol would need to remain unchanged.
The mode is hashcat -m 75000. The bitstreams are at
https://hashcat.net/bitstreams/, and docs/hashcat-fpga-setup.md covers
the setup for every board. For a sense of scale at bcrypt cost 5: one
ZTEX 1.15y, running John's own bitstream, does about 115 kH/s in
hashcat, and one YPCB card does about 130 kH/s.
2. John's dynamic formats in hashcat
hashcat can now load John's $dynamic_N$ hashes directly with
--dynamic-x. It covers 407 of the 409 dynamic formats built into John,
plus all 58 in John's dynamic.conf. The two missing formats are phpass
and HTTP digest (dynamic_17 and dynamic_21), which hashcat handles in
its own modes 400 and 11400.
These run as hashcat hash recipes, so they are GPU accelerated. On a
CPU, they run vectorized through the OpenCL CPU runtime.
The comparison below is from a Ryzen 9 7950X (16 cores, 32 threads)
with an RX 7900 XTX. The John build is bleeding-jumbo 5184bc0b8,
compiled with AVX-512 and run with --fork=32. The attack uses the
mask ?a?a?a?a?a?a?a?a against one hash.
format expression John hashcat hashcat
CPU CPU 1 GPU
dynamic_2 md5(md5($p)) 1102 1312 17543 MH/s
dynamic_8 md5(md5($s).$p) 1063 3020 27941 MH/s
dynamic_63 sha256(sha256($p)) 128 431 3233 MH/s
dynamic_1001 md5(md5(md5(md5($p)))) 571 731 8846 MH/s
With wordlists, the CPU picture is different. With a plain wordlist
and no rules, John's forks read candidates faster than hashcat feeds
its CPU device. John is faster in that case. With rules, hashcat on
the CPU is about as fast as John or faster, depending on the format.
Thanks,
Jens
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
