[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Mon, 23 Jul 2018 17:27:51 +0200
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Cc: Denis Burykin <apingis@...nwall.net>
Subject: sha512crypt & Drupal 7+ password cracking on FPGA
Hi,
As many of you are aware, we support descrypt and bcrypt password hash
cracking on the old ZTEX 1.15y quad-FPGA boards. Threads:
http://www.openwall.com/lists/john-users/2016/11/06/1
http://www.openwall.com/lists/john-users/2017/06/25/1
Now Denis has also added support for sha512crypt and Drupal 7+ SHA-512
based password hashes on those same old boards.
We had achieved energy-efficiency improvement over current high-end GPUs
at descrypt and bcrypt, and in the case of bcrypt also decent speed
improvement per board and per rig (see further messages in the above
threads). However, for sha512crypt and Drupal 7+ hashes we're merely on
par with current high-end GPUs in terms of energy-efficiency and our
speeds per-board are lower (it takes four or so boards to match one
high-end GPU). Thus, for practical purposes this is useful to those who
have those boards anyway or would acquire such boards primarily for
bcrypt and descrypt, so that the boards can also be put to more uses.
This is also valuable as being, to the best of my knowledge, the very
first implementation of these two hash types on FPGA. And it is also
our first attempt to use specialized soft CPU cores(*) along with
cryptographic cores in an FPGA design to combine some limited
flexibility (in this case, used to implement two higher-level hash types
in one bitstream) with resource savings (no need to waste logic on
sha512crypt's higher-level algorithm specifics) and efficient
cryptographic cores (in this case, SHA-512). Application of a similar
approach to newer and much larger FPGAs (such as those available on AWS
F1) will result in improvement over current GPUs at least in
energy-efficiency (and for the largest FPGAs probably also in
performance).
(*) Denis' bcrypt design uses microcode to save on logic, but it's a
closer match to historical CPUs' wide microcode than to a CPU program.
Maybe it'll help us implement bcrypt-pbkdf at some point, though.
Denis wrote a good description of the design with some ASCII diagrams,
currently found here:
https://github.com/magnumripper/JohnTheRipper/tree/bleeding-jumbo/src/ztex/fpga-sha512crypt
Each soft CPU core is 16-way SMT (runs 16 hardware threads with their
separate register files) and it controls four SHA-512 cores with each of
those capable of up to four in-flight hash computations (most of the
time only two are being computed, but there's some overlap between
finishing processing on one pair of hashes and starting on the next).
One soft CPU core (plus its memory and glue logic) and four SHA-512
cores form a unit. The SHA-512 cores occupy 80% of the unit's area,
so in those terms the overhead of using soft CPUs is at most 25% (but
they actually help save on algorithm-specific logic).
10 units fit in one Spartan-6 LX150 FPGA. This means 10 soft CPU cores,
160 hardware threads, 40 SHA-512 cores, up to 160 in-flight SHA-512 per
FPGA. Four times that per board.
Also included are on-device candidate password generator (for mask mode,
including in hybrid modes along with a wordlist coming from host, etc.)
and hash comparator (capable of up to 512 loaded hashes per salt; no
limit on total loaded hashes as that's handled on host). This is
similar to what Denis' designs for descrypt and bcrypt also have.
sha512crypt and Drupal 7+ hashes are two entry points into the program
memory. (The Drupal 7+ program is much simpler than sha512crypt's.
It could also be more efficient on a more specialized design since it
does not need unaligned access to the buffers, which we support for
sha512crypt. Yet it's good to have it along with sha512crypt
essentially for free.)
Per Xilinx tools, this design was supposed to work at 225 MHz.
Unfortunately, in our testing it only works at this frequency with very
few units built into the bitstream. We don't know exactly why (maybe
it's the power draw). With 10 units, the design works reliably for us
at 135 MHz on many boards tested, so that's what we set as the current
default. It also sometimes works at higher frequencies such as 160 MHz,
but other times not. This is configurable in john.conf.
Here's a test run against 512 of same-salt sha512crypt hashes (good for
quick reliability testing as all 512 are supposed to be cracked) on one
board (4 FPGAs) at 135 MHz:
$ ./john -2='1A2B3C4D5E6F7G8H9I0J' --mask='?2?2?2?2?2' --format=sha512crypt-ztex --verbosity=1 pw-sha512crypt
[...]
Loaded 512 password hashes with no different salts (sha512crypt-ztex, crypt(3) $6$ [sha512crypt ZTEX])
Press 'q' or Ctrl-C to abort, almost any other key for status
327g 0:00:00:42 62.00% (ETA: 15:55:22) 7.746g/s 47003p/s 47003c/s 16282KC/s 40447..40137
512g 0:00:01:05 DONE (2018-07-23 15:55) 7.825g/s 46950p/s 46950c/s 12179KC/s 40500..40190
Session completed
Four boards (16 FPGAs), 135 MHz:
$ ./john -2='1A2B3C4D5E6F7G8H9I0J' --mask='?2?2?2?2?2' --format=sha512crypt-ztex --verbosity=1 pw-sha512crypt
[...]
Loaded 512 password hashes with no different salts (sha512crypt-ztex, crypt(3) $6$ [sha512crypt ZTEX])
Press 'q' or Ctrl-C to abort, almost any other key for status
378g 0:00:00:12 72.00% (ETA: 15:53:55) 30.45g/s 185656p/s 185656c/s 62318KC/s 40348..1AF58
512g 0:00:00:16 DONE (2018-07-23 15:53) 30.89g/s 185395p/s 185395c/s 51138KC/s 40000..40140
Session completed
Scaling efficiency 185395/46950/4 = 98.7%.
Four boards (16 FPGAs), 160 MHz:
$ ./john -2='1A2B3C4D5E6F7G8H9I0J' --mask='?2?2?2?2?2' --format=sha512crypt-ztex --verbosity=1 pw-sha512crypt
[...]
Loaded 512 password hashes with no different salts (sha512crypt-ztex, crypt(3) $6$ [sha512crypt ZTEX])
Press 'q' or Ctrl-C to abort, almost any other key for status
174g 0:00:00:04 32.00% (ETA: 15:57:33) 36.78g/s 216490p/s 216490c/s 94714KC/s 40044..1AF54
512g 0:00:00:14 DONE (2018-07-23 15:57) 36.44g/s 218647p/s 218647c/s 60310KC/s 40000..40340
Session completed
This is similar speed to what Jeremi Gosney reported for hashcat on one
GTX 1080 Ti at stock clocks:
https://gist.github.com/epixoip/973da7352f4cc005746c627527e4d073
Hashtype: sha512crypt, SHA512(Unix)
Speed.Dev.#1.....: 216.0 kH/s (53.53ms)
Somehow a newer benchmark of 8x GTX 1080 Ti shows slightly higher speed
per GPU:
https://gist.github.com/epixoip/ace60d09981be09544fdd35005051505
Hashtype: sha512crypt $6$, SHA512 (Unix)
Speed.Dev.#1.....: 235.9 kH/s (96.29ms)
Speed.Dev.#2.....: 228.3 kH/s (50.67ms)
Speed.Dev.#3.....: 230.4 kH/s (50.22ms)
Speed.Dev.#4.....: 230.5 kH/s (50.18ms)
Speed.Dev.#5.....: 230.6 kH/s (50.16ms)
Speed.Dev.#6.....: 230.1 kH/s (50.27ms)
Speed.Dev.#7.....: 232.0 kH/s (49.85ms)
Speed.Dev.#8.....: 231.3 kH/s (50.01ms)
Speed.Dev.#*.....: 1849.1 kH/s
We're probably consuming around 160W for the boards (Denis measured 3.4A
at 12V per board at 160 MHz, which translates to ~40W/board) or 180W at
the wall at ~90% PSU efficiency.
I guess GTX 1080 Ti might consume a little bit more at this benchmark
(it's a 300W TDP card). Jeremi (or someone else who has one of those
cards) can probably check via nvidia-smi while running hashcat.
Drupal 7+ hash, one board (4 FPGAs) at 135 MHz:
$ ./john -2='pasword' --mask='?2?2?2?2?2?2?2?2' --format=drupal7-ztex pw-drupal7
[...]
Loaded 1 password hash (Drupal7-ztex, $S$ [SHA512 ZTEX])
Cost 1 (iteration count) is 16384 for all loaded hashes
Press 'q' or Ctrl-C to abort, almost any other key for status
0g 0:00:00:10 2.49% (ETA: 16:08:54) 0g/s 14250p/s 14250c/s 14250C/s prdowaap..oooarsap
0g 0:00:02:03 30.91% (ETA: 16:08:49) 0g/s 14421p/s 14421c/s 14421C/s awoppaas..rssoasas
0g 0:00:03:31 52.93% (ETA: 16:08:50) 0g/s 14427p/s 14427c/s 14427C/s wdwdwdow..pdawrprw
0g 0:00:06:20 95.21% (ETA: 16:08:51) 0g/s 14430p/s 14430c/s 14430C/s wpddwood..ppowrrod
password (?)
1g 0:00:06:28 DONE (2018-07-23 16:08) 0.002571g/s 14428p/s 14428c/s 14428C/s password..orpadord
Use the "--show" option to display all of the cracked passwords reliably
Session completed
Four boards (16 FPGAs), 135 MHz:
$ ./john -2='pasword' --mask='?2?2?2?2?2?2?2?2' --format=drupal7-ztex pw-drupal7
[...]
Loaded 1 password hash (Drupal7-ztex, $S$ [SHA512 ZTEX])
Cost 1 (iteration count) is 16384 for all loaded hashes
Warning: Slow communication channel to the device. Increase mask or expect performance degradation.
Press 'q' or Ctrl-C to abort, almost any other key for status
0g 0:00:00:10 10.23% (ETA: 16:01:23) 0g/s 56120p/s 56120c/s 56120C/s oaoopprp..rooddwrp
0g 0:00:00:35 35.24% (ETA: 16:01:26) 0g/s 56590p/s 56590c/s 56590C/s dwpadaws..ppawrrws
0g 0:00:01:01 60.25% (ETA: 16:01:27) 0g/s 56662p/s 56662c/s 56662C/s adwoowao..ssodwpso
password (?)
1g 0:00:01:39 DONE (2018-07-23 16:01) 0.01005g/s 56678p/s 56678c/s 56678C/s password..wsrssdrd
Use the "--show" option to display all of the cracked passwords reliably
Session completed
Scaling efficiency 56678/14428/4 = 98.2% despite of the complaint about
too small mask (too few different characters for the mask positions
handled on device).
Four boards (16 FPGAs), 160 MHz:
$ ./john -2='pasword' --mask='?2?2?2?2?2?2?2?2' --format=drupal7-ztex pw-drupal7
[...]
Loaded 1 password hash (Drupal7-ztex, $S$ [SHA512 ZTEX])
Cost 1 (iteration count) is 16384 for all loaded hashes
Warning: Slow communication channel to the device. Increase mask or expect performance degradation.
Press 'q' or Ctrl-C to abort, almost any other key for status
0g 0:00:00:12 14.78% (ETA: 16:11:22) 0g/s 65890p/s 65890c/s 65890C/s rpdroapa..dwdporpa
0g 0:00:00:31 36.38% (ETA: 16:11:25) 0g/s 66386p/s 66386c/s 66386C/s apawrrws..swarosos
0g 0:00:01:16 88.67% (ETA: 16:11:26) 0g/s 66586p/s 66586c/s 66586C/s soapawad..wpssppsd
password (?)
1g 0:00:01:24 DONE (2018-07-23 16:11) 0.01180g/s 66541p/s 66541c/s 66541C/s password..wsrssdrd
Use the "--show" option to display all of the cracked passwords reliably
Session completed
We'd appreciate more testing, such as on Royce' larger cluster of these
boards maybe. Please post your results as follow-ups to this message.
Alexander
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.
