Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 13 Apr 2012 15:59:27 -0400
From: Rich Rumble <richrumble@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: .chr files (Was: automation equipped working place
 of hash cracker, proposal)

On Fri, Apr 13, 2012 at 2:51 PM, Frank Dittrich
<frank_dittrich@...mail.com> wrote:
>> This is common and often very rewarding. What we should not forget
>> though, is that this will emphasize the errors we made in the first
>> case.
There is always a point of diminishing returns, it's probably still
best to create a custom chr, esp if there are a lot of candidates left
to try. Any progress is better than no progress, repeating passes is
almost a certainty.
> 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.
Has anyone ever looked at any bayesian "predictions"? I'm no CS
professor, but it may be a neat endeavor for someone to look at. There
may be too much information to make a likely prediction, perhaps
finding (less obvious)patterns based on C V or D.
> 3. Generating a .chr file which is appropriate for different hash
> algorithms is very hard.
The hash algorithms has next to nothing to do with chr files, but
there are/is an exception, LM clearly (all upper/69 printable
characters) has a limited character set. I suppose length could be a
factor in chr files, so a hash limited to 7 chars like LM, or DES
being limited to 8. I don't know how much the length of the hash has
to do with a chr file if anything. Nonetheless while there are
Digits/Alnum/All chr sets, they work for all hash types typically.
-rich

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.