Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 28 Jan 2007 14:47:39 +0300
From: Solar Designer <>
Subject: Re: how to find a password of 16 digits


I wrote:
> >[Incremental:Digits16]
> >File = $JOHN/digits16.chr
> >MinLen = 16
> >MaxLen = 16
> >CharCount = 10
> >
> >Note that this new digits16.chr will also work for lengths 0 to 15, if
> >you ever need that.

On Sun, Jan 28, 2007 at 11:58:59AM +0100, Frank Dittrich wrote:
> Why do you need a new chr file?
> Wouldn't the original digits.chr file work as well (or a poorly,
> for that matter)?

No, it would not work at all.  Once you recompile JtR with different
CHARSET_* settings, the .chr file format changes.

> I didn't recompile JtR for incremental mode with length 16, but your
> example looks like John tries 2222222222222222, then all passwords
> containing just the digits 2 and 4 (and at least one digit 4), then
> all passwords containing at least one digit 0 and only digits 2, 4,
> and 0, and so on.

That's true.  Essentially, the information on what digits are likely to
be seen together (or the conditional probabilities) is lost with such a
length expansion.

> Just assume you want to crack case insensitive passwords of length 8.
> There's no suitable .chr file, so you could use:
> [Incremental:lanman8]
> File = $JOHN/lanman.chr
> MinLen = 8
> MaxLen = 8
> CharCount = 69

Yes, this would work - because you do not need to recompile JtR for it.

And, yes, it simulates the same length expansion well.  There's no
information specific to length 8 within lanman.chr, so JtR has to
fallback to using the "global" list of characters ordered for decreasing
frequency (such a list is included in all .chr files).

> IMO this proves that such statistical information from shorter
> passwords is of limited use for longer passwords.

I'd say that it proves that this specific approach of length expansion
is rather poor.

I think that better results would be achieved by placing pairs of
8-digit candidate passwords on each john.pot line (for 16-character
"cracked" passwords).

> I just want to mention this to emphasize that, without additional
> knowledge about the password, you shouldn't hope to find the
> correct password easily, no matter what method you use,

Indeed.  The keyspace is very large, so more information on likely
16-digit passwords is needed.  I think that a pool of credit card
numbers would work really well to train JtR, if Johnny has that. ;-)
If not, then maybe the output of a credit card number generator program
(such as THC-Credit) would work fine, too.  I don't know if these
programs would output lots of numbers to a file (haven't tried
downloading them), but I'd expect so.

> because the key space of 16 digit passwords is larger than the
> key space of DES passwords (up to 8 characters, with CharCount 95).

Oh, it's only a little bit larger, so that's not the primary problem.
It all depends on how the likely passwords are distributed within that
space and what information we have on that distribution.

Alexander Peslyak <solar at>
GPG key ID: 5B341F15  fp: B3FB 63F4 D7A3 BCCC 6F6E  FC55 A2FC 027C 5B34 1F15 - bringing security into open computing environments

To unsubscribe, e-mail and reply
to the automated confirmation request that will be sent to you.

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ