Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 17 Jun 2006 04:36:59 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re:  Re: Inverted chatsets?

On Sat, Jun 17, 2006 at 12:54:11AM +0300, Pietari Kivikangas wrote:
> Total amount of all possible password candidates: 6634204312890625

That's correct, for the 95 printable US-ASCII characters and passwords
of exactly 8 characters long.

> Approximated total number of password candidates within the 'rec_entry' 
> value 3000: 0x00000057cfdce769 = 377149515625, i.e. about 0.00568% of 
> all passwords.
> Approximated total number of password candidates within the 'rec_entry' 
> value 3419: 0x00003afa8baa2780 = 64847759419264, i.e. about 0.97748% of 
> all passwords.

I'm not sure how you've derived those numbers, but they look reasonable.

> So in both cases the probability for a single candidate is equal,

That's just your assumption.

In John the Ripper, each candidate password in entry 3419 is assumed to
be less likely to be one of the passwords that we're searching for than
any candidate password in entry 3000.  That's the whole point in ordering
the candidate passwords in this way.

> i.e. 0.00568% / 377149515625 = 0.97748% / 64847759419264 = 

You've merely checked your own math here.  You have not proven anything.

> But for the 'rec_entry' value 3419 there are much more password
> candidates than for 3000.

That's true.  So not only each of them is less probable but there are
also more of them - making it even more unreasonable to do the search
backwards as Phantom has suggested.

-- 
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

Your e-mail address:

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