Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 9 Jul 2012 01:36:48 +0200
From: Frank Dittrich <>
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)?


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.