|
Message-ID: <4B946194.3050200@bredband.net> Date: Mon, 08 Mar 2010 03:31:48 +0100 From: "Magnum, P.I." <rawsmooth@...dband.net> To: john-users@...ts.openwall.com Subject: Re: Feedback on the generic crypt(3) patch >> Sorry again for the spamming, I really thought I got it right but I got >> the lengths wrong despite what I thought were valid double-checks. I >> enclose a fixed fix of the fix. Like before, this patch can be applied >> after Solar's "john-1.7.3.1-generic-crypt-1.diff.gz" > > This is still not quite it. The encoding strings for SHA-crypt hashes > are not always of fixed length. This is only the case when the default > iteration count is used (and so it is not specified). Please see: > > http://people.redhat.com/drepper/SHA-crypt.txt > http://www.php.net/manual/en/function.crypt.php Thanks. The last patch I posted will put out correct benchmark figures anyway so I'll spare you any more versions until I have completed my homework. > Also, when you modify a source file written by someone else, I'd > appreciate it if you introduce or edit a comment to state so, as well as > what terms apply to your modifications (perhaps place them in the public > domain just like I did for the original crypt_fmt.c file). I didn't add any real code so I thought it was obvious. For the record, my little contributions are hereby placed in the public domain. >> Another strange thing though. I made up a password file of 1000 entries >> using the same salt. SHA-256 performs at ~275000 c/s and SHA-512 at >> 119000 c/s. The benchmarks report figures (for "same salt" too) in order >> of 1/1000 of that. When I test the same using different salts, it >> performs at about the speed as reported by the benchmark. This tells me >> there is actually a benefit of duplicate salts > > Indeed. > >> which is a surprise in itself, > > Why is it? The hash computation only needs to be performed once per > {candidate password, salt}. When you have many target hashes with the > same salt, your effective rate of {candidate password, target hash} > increases a lot - and this is what JtR reports while cracking. But of course. I was confusing the above with the below, but it's really two different matters... > You may notice that it nevertheless does report two numbers - for "one > salt" and for "many salts", respectively, and these differ from each > other a little bit - e.g., by around 10% for traditional DES-based > crypt(3) hashes. This difference is primarily due to key setup > "overhead". The key setup only needs to be done once per candidate > password, whereas the hashing needs to be performed once for every > {candidate password, salt} combination. This means that with multiple > salts the key setup is performed less frequently than it is with just > one salt, and thus the rate of hash computations per second increases. This makes sense but again I tend to confuse it with what you explained in the previous quote. I guess I need to stop and think. > For SHA-crypt, this effect should not be seen (any differences between > the two numbers that you might see are either spurious or indicative of > an implementation shortcoming). Why shouldn't it be seen for SHA-crypt? Because key setup overhead will be insignificant compared to hashing? FreeBSD MD5, among others, only reports a "Raw" figure, why is that? I can understand why saltless hashes do that. thanks magnum
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.