Date: Wed, 5 Apr 2006 00:16:18 +0400 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: JTR and Speed On Tue, Apr 04, 2006 at 07:08:47PM +0200, websiteaccess@...il.com wrote: > Loaded 1 password hash (Traditional DES [128/128 BS AltiVec]) > guesses: 0 time: 0:00:00:10 5% c/s: 507827 trying: wi46 - wins46 > John25 (test) > guesses: 1 time: 0:00:00:16 100% c/s: 503350 trying: Jklmno25 - Joonas25 > > > When I try to crack 527 encrpyted (same wordlist used), I use my own > wordlist, I have 5350K (5,350,000) c/s ! (see below) > ------------------------------------------------- > Loaded 527 password hashes with 90 different salts (Traditional DES > [128/128 BS AltiVec]) > guesses: 0 time: 0:00:00:02 0% c/s: 5350K trying: jetski - jism > > Could you tell why that difference between 507827 and 5,350,000 c/s ? There are two reasons: 1. Matching salts. In your second example, you have 527 password hashes with only 90 different salts - meaning that you have around 6 password hashes per salt on average. For each candidate password (from your wordlist), John only needs to calculate 90 different hashes, not 527 - yet that is sufficient for checking the candidates against all of the loaded 527 password hashes. 2. Per-candidate "overhead". John has to read each candidate password from your wordlist file and to set it up as a cryptographic key to be tried. If you're using word mangling rules, the processing cost of that is added, too. With only one password hash loaded, these operations are performed for each password hash calculated and checked. With multiple hashes loaded, these per-candidate operations are only performed once for all password hash calculations and checks based on this candidate - for all salts. Both of these contribute to a higher effective combinations per second rate with more password hashes loaded for cracking simultaneously. BTW, it is uncommon to have only 90 different salts with 527 hashes. This indicates a problem with the way salts were being generated on the target system. -- 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.