[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060616174929.GB6546@openwall.com>
Date: Fri, 16 Jun 2006 21:49:29 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Inverted chatsets?
On Fri, Jun 16, 2006 at 05:16:25PM +0000, Phantom wrote:
> Was wondering if you would consider an option/switch for creating
> "inverted charsets" using the opposite of the algorithm used to create the
> default charsets.
[...]
> This might be complete nonsense, ...
This is not complete nonsense, but it is very close to being nonsense.
What would those "inverted charsets" be? all.chr already includes all
the printable US-ASCII characters, so the inverted character set would
be empty, provided that we continue to restrict ourselves to US-ASCII.
So you must be talking about "inverting" character frequencies, not the
character set. That would mean that we treat the characters and
character combinations that were most commonly seen in our sample
passwords as the least likely ones, and instead treat the characters and
character combinations that were never seen as the most likely ones. In
other words, we would sort of start our search from the "end" of the
list of candidate passwords that "incremental mode" normally generates.
Of course, chances are that we won't get any passwords cracked in any
reasonable amount of time in this way.
On the other hand, if you, for example, have run digits.chr and then
proceed to run all.chr, you actually want to exclude all-numeric
passwords from those produced by -i=all. Right now, the only way to do
that is with an external filter(). But you might as well choose to not
do it since all-numeric passwords correspond to a small portion of the
password space, whereas filtering has a certain processing cost for all
candidate passwords (including those that contain non-digits). This
example also serves to illustrate one reason why I suggest that people
go for all.chr (or lanman.chr) right away, without bothering with the
more restrictive charsets.
--
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.
