[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BLU0-SMTP434B4ADE04FAA9D27F6F635FD3B0@phx.gbl>
Date: Fri, 13 Apr 2012 23:14:24 +0200
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-users@...ts.openwall.com
Subject: Re: .chr files
On 04/13/2012 10:46 PM, Aleksey Cherepanov wrote:
> On Fri, Apr 13, 2012 at 08:51:31PM +0200, Frank Dittrich wrote:
>> 1. If you already used incremental mode with another .chr file for a
>> while before you build a new .chr file and restart incremental mode with
>> the new file, you'll inevitably try a certain amount of candidate
>> passwords again which have already been tried before.
>> This is even more the case if you repeatedly recreate new .chr files
>> based on passwords cracked previously.
>
> We could filter out candidates that we already tried. Though it does not solve
> problem, only reduces it a bit (if effective at all).
For very slow hashes this could even be an option, for faster ones this
would probably generate too much overhead.
We should just be aware of the possible negative effects of switching
.chr files too frequently when deciding about how to proceed.
>> A solution could be to generate a .chr file once after a reasonable
>> amount of passwords have been cracked.
>
> I think it is possible to calculate how much is reasonable: first candidates
> are closer to pattern than further candidates so success with first candidates
> effect regenerated .chr file less than success with successive candidates,
> if we could measure effect of each candidate became password and compare total
> effect with cost of restart then we could restart precisely. Though
> approximate estimation could be enough.
I'm afraid we'll have limited capacities for such measurements during
the contest.
We could try to simulate the situation prior to the contest, may be
using samples of fast, saltless hashes, or even --format=dummy, with a
large enough list of previously cracked passwords...
The knowledge we gain from such simulations could influence the strategy
chosen during the contest.
While doing such such simulations might deliver some insights, they'll
hardly result in new or enhanced tools developed by you, so it is
questionable whether this should be part of your GSoC project.
>> If you later on generate new .chr files, you can start new incremental
>> mode sessions and run them as long as they are effective (due to newly
>> discovered important tri-graph character sequences, compared with the
>> previously created .chr files.
>> But when the new incremental mode session gets less effective, it might
>> be better to continue using the older incremental mode session which
>> already covered a larger part of the total key space.
>>
>> 2. If you detect a pattern like passwords based on dates, e.g.
>> 12/10/1989, and you try all candidate passwords of this pattern, you
>> should filter out all passwords of this pattern before generating a .chr
>> file.
>> Otherwise your .chr file will be biased, and password candidates of the
>> pattern DD/MM/YYYY or MM/DD/YYYY will become more likely, even if none
>> of those passwords will crack any remaining hashes.
>> The same applies if someone already completed incremental mode with
>> digits.chr.
>> In this case, you should filter out all passwords consisting only of
>> digits, to avoid a bias towards digits which will not be justified.
>
> We did this during the contest and practice proved its effectiveness. So to
> filter out cracked patterns from further cracking would be nice. But if we
> totally drop some pattern from cracking and this was subpattern then it would
> be much harder to find real pattern hence proposal not to drop pattern totally
> but rather reduce its effects (for instance keeping older increment mode
> session in use too like described above). Also it makes the question about
> quality of patterns found more important.
I think this has to be evaluated manually, and cannot easily be done
automatically.
If you think there is a more general form of a pattern, and you merely
tried a sub-pattern so far, you could try to test the more general
pattern on a subset of the remaining passwords, or you could just leave
some passwords matching the sub-pattern in the .pot file which is used
to generate a new .chr file.
There's probably no simple rule which always works best.
(All you can do is give some educated guesses, your assumptions may
always be proven wrong later on.)
I'm afraid I am currently too tired for the remaining part of your
reply, so I'll have a closer look at it tomorrow.
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.
