[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 7 Jul 2012 20:37:39 +0200
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: Re: optimized mscash2-opencl
On 07/07/2012 11:48 AM, Solar Designer wrote:
> On Sat, Jul 07, 2012 at 01:31:06PM +0400, Solar Designer wrote:
>> Actual run:
>>
>> $ ./john -i=alpha ~/john/contest-2011/hashes-all.txt-1.mscash2 -fo=mscash2-opencl -pla=1
> [...]
>
> I let this run until:
>
> guesses: 67 time: 0:00:28:24 0.00% c/s: 102413 trying: bara - choedia
> Use the "--show" option to display all of the cracked passwords reliably
> Session aborted
>
> Somehow john.pot and john.log were not being updated during the run,
> even though they should have been updated every 10 minutes.
I didn't check the code. Could this be related to the fact that john was
working in the same bara - choedia MAX_KEYS_PER_CRYPT block of passwords?
> Also notice how we stayed within the same "bara - choedia" set of
> candidate passwords for half an hour. It'd take roughly:
>
> 262144*1090/102413 = 2790 seconds
>
> to advance any further.
>
> Maybe max_keys_per_crypt is too high for convenient use. We could want
> to try reducing it and see if we're able to keep the speed almost as high.
Definitely.
What happens if you delete those 67 hashes from john.pot and restore the
session?
Will john restart processing the bara - choedia block for all hashes, or
does the john.rec file really store information about how many
salts/hashes have already been processed for this particular block?
I always thought this kind of information is not stored in a .rec file.
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)
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.
