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.