[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20060618172456.GA17639@openwall.com>
Date: Sun, 18 Jun 2006 21:24:56 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Cracking Speed
On Sun, Jun 18, 2006 at 06:10:36PM +0200, raggeler wrote:
> I have read the FAQ and there's something written about the c/s...
>
> "The values displayed by John mean combinations (of username and
> password) per second, not crypts per second."
>
> So, if I have for example 8 hashes in the hashfile, it will
> approximately return 8 times more c/s as if I just have one hash in the
> password file. Thats correct?
For saltless hashes, this is almost correct. I am saying "almost"
because setting up cryptographic keys and computing the hashes are not
the only operations that John has to perform. It also has to generate
candidate passwords to try and it has to compare computed hashes against
the ones loaded for cracking (although for fast hashes it usually does
those comparisons indirectly - with an O(log2(N)) algorithm operating on
bit vectors or with hash table lookups).
For salted hashes, when the loaded hashes actually have different salts,
the above statement is not correct. The ratio between the "raw" and the
effective c/s rate will be close to that between the number of different
salts and the number of hashes. However, even when the number of
salts matches the number of hashes exactly (that is, there are no
matching salts at all), the effective c/s rate might grow slightly along
with the number of hashes loaded for cracking. That's because candidate
passwords have to be generated and cryptographic keys setup only once
for each candidate, not once per salt.
> So 20'000'000 c/s does not mean that John tested 20'000'000 passwords,
> he just tested 20'000'000 / <hashcount>, that's right?
Almost. In practice, the number of remaining uncracked hashes decreases
as John runs, so it is not always so simple to calculate the rate at
which different candidate passwords are tried.
Obviously, I should enhance John to keep track of both rates and also to
report both average and current rates. Unfortunately, that won't fit on
the current status line.
--
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
Was I helpful? Please give your feedback here: http://rate.affero.net/solar
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.
