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.