[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <BLU0-SMTP1616E168F57FFE929945ECCFDEC0@phx.gbl>
Date: Mon, 9 Jul 2012 01:36:48 +0200
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: Re: optimized mscash2-opencl
On 07/08/2012 11:36 AM, Solar Designer wrote:
> On Sat, Jul 07, 2012 at 08:37:39PM +0200, Frank Dittrich wrote:
>> In that case, john would have to do almost all the work already done so
>> far again if you interrupt the session while it didn't finish the first
>> MAX_KEYS_PER_CRYPT block. (The only speedup would be due to the reduced
>> number of different salts)
>
> Exactly.
That's bad. Then you never know how much work you loose if you interrupt
a running session - except if you just watched john starting to work on
a new set of candidates.
> This was not designed for large KPCs with slow hashes. We may need to
> solve this in some way. Here are some ideas:
>
> 1. Do record info on salts tried / not yet tried for the current keys
> block. This is tricky to implement.
Thisgets very tricky, and will change the behavior in a way that might
be unexpected by the user.
hat if you want to reduce load time, and use --show=LEFT to create a
reduced input file for an interrupted session you want to restart.
Currently this just works.
[...]
> I don't particularly like any of these options. :-( That said, we do
> need formats to support a variety of KPC settings (not a compile-time
> constant only) for other reasons as well - such as because of the single
> crack mode memory consumption issue, and for running with small
> wordlists (may have fewer entries than e.g. MSCash2's 256k KPC).
I always thought ^C would cause john to run until the current block of
candidate passwords is completed for all salts before the session ends.
(At least the first ^C - I thought that's why sometimes you have to wait
a little longer looking at that "Wait..." message.
If that is currently not the case, this should at least be behavior that
can be activated by a config variable.
The comment could warn the user that he's possibly need to wait quite a
long time. (If during that time new password hashes get cracked, the pot
file must of course be updated again.
May be we could even introduce reacting on a signal other than 1 to
interrupt after a MAX_KEYS_PER_CRYPT (or MIN_KEYS_PER_CRYPT during
single mode) block has been finished.
What about -s 10 (SIGUSR1)?
Frank
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.
