|
Date: Tue, 4 Apr 2006 22:26:17 +0200 From: "websiteaccess@...il.com" <websiteaccess@...il.com> To: john-users@...ts.openwall.com Subject: Re: JTR and Speed > > 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. Thank you for you fast reply :)
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.