Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 08 Mar 2010 03:31:48 +0100
From: "Magnum, P.I." <>
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-"
> 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:

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 

> 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.


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.