[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 14 May 2019 12:20:40 +0200
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: ZTEX: timeouts and optimizing?
Hi Vincent,
On Tue, May 14, 2019 at 12:37:38AM +0200, Vincent wrote:
> I'm playing with john and some ZTEX boards. Some unexpected errors are shown
> once in a while:
>
> <cracking starts>
> ..
> SN <removed>: Timeout.
> Found 1 device(s) ZTEX 1.15y
> SN: <removed> productId: 10.15.0.0 "inouttraffic JtR 1.8.x" busnum:1
> devnum:36
> ..
> <cracking continues>
Yes, this can happen once in a while, and it hurts the average speed as
the timed-out device remains unused for a while. If this is infrequent
enough, you could just accept it.
BTW, to automatically remove SNs from JtR output, you can list them in
the [List.ZTEX:Devices] section in john.conf. Then they'll be replaced
with device numbers in JtR output, and also you'll be able to refer to
devices by number in the "--devices" option.
> Some questions:
> - Are there user settings that might fix this (e.g. frequency)?
For some hash types you need to adjust TargetSetting or TargetRounds in
the corresponding john.conf sections, to match the loaded hashes'
iteration counts. JtR warns you when this is needed.
Lowering the frequency could help, but in another message you already
say it didn't help you. Lowering the frequency too much could actually
trigger timeouts in some cases.
Excluding specific boards that are most problematic for specific hash
types could also help, if you have many boards. You can use the
"--devices" option to do this without having to physically disconnect or
power off any boards. As you say, all of them work fine for
bcrypt-ztex, so you wouldn't want to permanently disconnect any.
Sometimes also replacing USB cables or hubs helps. This is unlikely to
help in your case since you say bcrypt-ztex works reliably for you, but
it's still possible that this will help because USB traffic patterns
vary between hash types (and bcrypt-ztex commonly uses relatively little
bandwidth), so some might expose a problem that others don't.
On a related note, use of "--mask" (maybe along with other cracking
modes) reduces USB traffic, so might help hide USB-related problems too.
It's also useful to observe how the timeouts/errors are distributed
between different FPGA numbers on each board. If they're similarly
common for all 4 FPGAs, this would suggest a USB problem. If some FPGAs
exhibit errors far more frequently than others, this would suggest that
our specific design just doesn't work reliably on those specific chips
(at least at the specific frequency).
> - Are guesses lost as the result of the time-outs?
Some processing is lost (whatever the board managed to do just before it
got into a wrong state and timed out), but it's then redone, so
everything crackable in that session is supposed to be cracked anyway.
If anything that should doesn't get cracked, that's not because of
timeouts, but rather because of potential undetected errors.
> - What's a good way to determine the maximum speed of individual boards?
> - If clocked too high, will a board just hang of will guesses be wrong?
We're testing with many same-salt hashes, where many (or even all) of
the attempted candidate passwords are expected to crack some hash. Then
we make sure that everything actually does get cracked. Sometimes too
high a frequency primarily results in timeouts. Sometimes a moderately
too high frequency may first result in a small percentage of missed
cracks, but no timeouts. Sometimes it's a mix of both. You can see
such examples in some postings by me and by Royce.
I hope this helps, and thank you for giving this functionality a try.
If you don't mind, could you please share some statistics with us - how
many boards out of how many you have exhibit these timeout problems for
which hash types, their iteration count settings, hash and salt counts?
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.
