[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20051231032419.GB23367@openwall.com>
Date: Sat, 31 Dec 2005 06:24:19 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Re: john improvement suggestions - bigcrypt optimization
On Thu, Dec 22, 2005 at 02:32:56AM +0000, Radim Horak wrote:
> I understand that this universal solution is quite complex, but there could be
> much more simpler hack. At startup (or before processing a wordlist rule) john
> could analyze:
> 1) in incremental mode - if definition contains MaxLen <8 then discard all known
> 8-char-password-hashes from memory,
Yes, this can be implemented with no performance impact - only some
added code complexity. I had considered this before, but didn't get
around to implementing it, in part because I am not sure if it's worth
it (extra complexity for rarely used password hash types and uncommon
settings).
> or if actual length <8 then skip them until change of length.
John currently does not flush its buffers when it switches to a new
length with "incremental" mode. In order to implement what you suggest,
it would have to either start flushing buffers (running bitslice DES
with actual candidate passwords in only _some_ bit layers, etc.) or
implement pairs of buffers as I have explained in my previous response
on this topic. I don't like either approach very much.
> 2) in wordlist mode without rules - this could not be reasonably done, but
> 3) in wordlist mode with rules - detect if certain rule will generate maximum <8
> char length passwords (ie. with "<8" or "'7" rule) - skip the known-length
> hashes until next rule. These rules can then be used as a guides with custom
> wordlists.
This has the same difficulty as with "incremental" mode's length
switches and more: currently, John has no easy and reliable way to know
if a given wordlist rule can produce candidate passwords of a given
length. It would have to implement some sort of AI or heuristics (e.g.,
look for typical substrings in wordlist rules), or the wordlist rule
processor would need to be enhanced to optionally keep track of possible
candidate password lengths (rather than only of actual lengths).
There's also the option to let wordlist rules be manually flagged as
(not) producing passwords of certain lengths.
To summarize, advanced handling of bigcrypt-alike password hashes is not
something I am likely to implement soon, if at all.
Thanks,
--
Alexander Peslyak <solar at openwall.com>
GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 B35D 3598
http://www.openwall.com - bringing security into open computing environments
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.
