[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 1 Jul 2017 14:08:36 -0800
From: Royce Williams <royce@...ho.org>
To: john-users@...ts.openwall.com
Cc: Denis Burykin <apingis@...nwall.net>
Subject: Re: DES-based crypt(3) cracking on ZTEX 1.15y FPGA
boards (descrypt-ztex)
On Fri, Jun 30, 2017 at 10:36 AM, Solar Designer <solar@...nwall.com> wrote:
> On Fri, Jun 30, 2017 at 07:22:33PM +0200, Solar Designer wrote:
>> An easier (and better?) workaround is to buffer even more candidate
>> passwords within 1 process. On my Qubes system, adding this line:
>>
>> +++ b/src/ztex/device_format.c
>> @@ -111,6 +111,7 @@ void device_format_reset()
>> // Mask data is ready, calculate and set keys_per_crypt
>> unsigned int keys_per_crypt = jtr_bitstream->candidates_per_crypt
>> / mask_num_cand();
>> + keys_per_crypt *= 4;
>> if (!keys_per_crypt)
>> keys_per_crypt = 1;
>>
>> makes the standard clocks c/s rate increase from 806M to 828M, which
>> suspiciously matches the theoretical maximum Denis gives for the current
>> design in the just committed src/ztex/fpga-descrypt/README.md:
>>
>> https://github.com/magnumripper/JohnTheRipper/pull/2598/commits/1214de42284c8b66728f0f8fd362a743f54c2ab0#diff-c70cc4e9666091acde7a844bfc24d88d
>>
>> This appears to work. The cracked passwords stream isn't expected to be
>> exactly the same (that is, not in the same order) because the larger
>> buffers unfortunately result in less optimal ordering of the candidates
>> with incremental mode and the like.
>>
>> Also, the total running time of some short sessions (in my testing:
>> mask, but not wordlist) appears to increase - perhaps the very last
>> crypt_all() call (for each salt) hashes many more keys than are actually
>> supplied? Denis, perhaps this is something you could fix?
>>
>> Royce, unless Denis says this hack is somehow very wrong, feel free to
>> try it on your cluster, and maybe you'll regain some of those lost ~15%.
>>
>> Please note that this code is also used for bcrypt (and the change gives
>> me slight speedup for bcrypt, too - about 2%, which were presumably lost
>> to USB pass-through - just not that much of a speedup, because the
>> performance hit on it wasn't that bad in the first place).
>>
>> So if you do go for this, please test bcrypt both ways (without and with
>> this change) as well. Perhaps keep two john binaries.
>>
>> keys_per_crypt factors other than 4 (such as 2, 3, 5, more) on this line
>> may also be tried. I only tried 4 - I didn't tune. Denis, maybe make
>> this configurable?
>
> Testing this with the multiplier set to 8, I get the speeds to stabilize
> at the unrealistic(?) for standard clocks figure of 831M. Could be
> misreporting, but the actual results look OK.
>
> $ ./john -form=descrypt-ztex -inc=lower -min-len=8 -max-len=8 -mask='?w?l?l?l?l' pw-fake-unix
> ZTEX XXXXXXXXXX bus:2 dev:7 Frequency:220,160 220,160 220,160 220,160
> Using default input encoding: UTF-8
> Loaded 3269 password hashes with 2243 different salts (descrypt-ztex, traditional crypt(3) [DES ZTEX])
> Press 'q' or Ctrl-C to abort, almost any other key for status
> 0g 0:00:00:12 0g/s 0p/s 877393Kc/s 1267MC/s loveaaaa..loveaovd
> 0g 0:00:00:14 0g/s 0p/s 835613Kc/s 1169MC/s loveaaaa..loveaovd
> 0g 0:00:00:15 0g/s 0p/s 857896Kc/s 1247MC/s loveaaaa..loveaovd
> 0g 0:00:00:16 0g/s 0p/s 877393Kc/s 1316MC/s loveaaaa..loveaovd
> 0g 0:00:00:18 0g/s 0p/s 844897Kc/s 1364MC/s loveaaaa..loveaovd
> 0g 0:00:00:19 0g/s 0p/s 862001Kc/s 1416MC/s jayotuhb..loveaovd
> 0g 0:00:00:46 0g/s 0p/s 839246Kc/s 1246MC/s loveaaaa..loveaovd
> campbell (u1822-des)
> 1g 0:00:00:47 0.02086g/s 0p/s 846280Kc/s 1244MC/s campbell..loveaovd
> 1g 0:00:00:49 0.02027g/s 0p/s 835613Kc/s 1217MC/s loveaaaa..loveaovd
> [...]
> manageme (u2347-des)
> 10g 0:00:07:19 0.02276g/s 0p/s 831425Kc/s 1183MC/s loveaaaa..loveaovd
> jethrotu (u1131-bigcrypt:1)
> jeepster (u2212-des)
> metallic (u706-des)
> 13g 0:00:08:31 0.02543g/s 0p/s 831034Kc/s 1179MC/s loveaaaa..loveaovd
> michigan (u2378-des)
> 14g 0:00:09:30 0.02455g/s 0p/s 831215Kc/s 1173MC/s loveaaaa..loveaovd
> peterpan (u2501-des)
> butterfl (u1812-bigcrypt:1)
> californ (u970-bigcrypt:1)
> 17g 0:00:10:40 0.02653g/s 0p/s 831696Kc/s 1177MC/s loveaaaa..loveaovd
> lissabon (u2310-des)
> [...]
> babydoll (u921-des)
> 91g 0:00:47:05 0.03220g/s 0p/s 831117Kc/s 1212MC/s loveaaaa..loveaovd
> bluejean (u1775-des)
> moonbeam (u2405-des)
> motorola (u2409-des)
> shanghai (u2653-des)
> alexandr (u534-des)
> lonestar (u2319-des)
> jethrotu (u1131-des)
> 98g 0:00:52:29 0.03111g/s 0p/s 831049Kc/s 1210MC/s loveaaaa..loveaovd
> paradigm (u2479-des)
> 99g 0:00:52:37 0.56% (ETA: 2017-07-07 08:05) 0.03135g/s 370489p/s 831166Kc/s 1211MC/s sunoaaaa..sunoaovd
> promethe (u1286-des)
> 100g 0:00:52:50 0.56% (ETA: 2017-07-07 08:43) 0.03154g/s 369009p/s 831079Kc/s 1211MC/s sunoaaaa..sunoaovd
> kristine (u2280-des)
> 101g 0:00:54:27 0.56% (ETA: 2017-07-07 13:32) 0.03091g/s 358039p/s 831111Kc/s 1211MC/s sunoaaaa..sunoaovd
> treasure (u2814-des)
> 102g 0:00:56:00 0.56% (ETA: 2017-07-07 18:09) 0.03035g/s 348136p/s 831087Kc/s 1214MC/s sunoaaaa..sunoaovd
> chainsaw (u1843-des)
> promethe (u1286-bigcrypt:1)
> softball (u3082-des)
> 105g 0:00:56:58 0.56% (ETA: 2017-07-07 21:01) 0.03071g/s 342261p/s 831017Kc/s 1212MC/s sunoaaaa..sunoaovd
> transpor (u2809-bigcrypt:1)
> superman (u334-des)
> 107g 0:00:57:54 0.56% (ETA: 2017-07-07 23:48) 0.03079g/s 336714p/s 831091Kc/s 1211MC/s sunoaaaa..sunoaovd
>
> Comparing this to the results I posted earlier, standard clocks:
>
> brewster (u1794-des)
> 99g 0:00:49:45 0.49% (ETA: 2017-07-06 17:59) 0.03316g/s 342899p/s 806212Kc/s 1168MC/s lynnaaaa..lynnaays
> superman (u334-des)
> 100g 0:00:54:43 0.56% (ETA: 2017-07-06 11:37) 0.03045g/s 356327p/s 806126Kc/s 1168MC/s suno####..jmbp####
>
> Old 5% overclock (w/o the hack):
>
> brewster (u1794-des)
> 99g 0:00:47:39 0.49% (ETA: 2017-07-06 09:17) 0.03462g/s 358015p/s 840055Kc/s 1217MC/s lynnaaaa..lynnaays
> superman (u334-des)
> 100g 0:00:52:15 0.56% (ETA: 2017-07-06 02:43) 0.03189g/s 373136p/s 839891Kc/s 1218MC/s sunoaaaa..sunoaays
>
> So in terms of passwords cracked, this hack is similar to but not
> exactly at the 5% overclock level, but without the overclock. It will
> probably be of a lot more help with multiple boards per host, but I
> might as well guess wrong.
Some quick keys_per_crypt tests on the cluster.
A value of 2 was a ~5.4% improvement. Values above 2 were worse -
enough that I only let them run for a few minutes to verify.
Stock:
325g 0:00:59:59 0.49% (ETA: 2017-07-08 16:38)
0.09029g/s 4550Kp/s 9881Mc/s 14078MC/s nujuaaaa..nujualks
With keys_per_crypt *= 2:
369g 0:01:29:18 11.76% (ETA: 08:01:28)
0.06886g/s 4585Kp/s 10454Mc/s 14840MC/s ayceaaaa
With keys_per_crypt *= 3:
269g 0:00:30:43 0.88% (ETA: 2017-07-04 07:01)
0.1459g/s 1001Kp/s 3267Mc/s 4693MC/s shzbaaaa..shzbajwz
With keys_per_crypt *= 4:
16g 0:00:02:11 0.1215g/s 0p/s 5201Mc/s 7639MC/s loveaaaa
With keys_per_crypt *= 8:
25g 0:00:04:48 0.08667g/s 0p/s 2389Mc/s 3529MC/s majordom
32g 0:00:05:39 0.09428g/s 0p/s 2390Mc/s 3493MC/s garcdlyg
40g 0:00:07:19 0.09092g/s 0p/s 2395Mc/s 3413MC/s puggtbta
Royce
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.
