Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 7 May 2013 9:18:38 -0400
From:  <>
Subject: Re: Enhancements to pbkdf2-sha256

---- Solar Designer <> wrote: 
> > We should split aix-ssha into three different formats (in one same source file).
> Yes, because they're of different speed, so those hashes are better
> cracked separately (more candidate passwords may be tested against the
> faster hashes).
> > We currently benchmark a mix of test vectors :-/
> We only use first two salts for benchmarking, which currently (in
> aix_ssha_fmt.c in bleeding) correspond to {ssha1}06.  That's just 128
> SHA-1's, right?  I am surprised the speed is not higher.

I have split these 3. They still have single common source file.  Also 'many' functions are all single (crypt_all, all the cmp, salt, etc). They have unique valids, unique self tests, unique format names (algo, etc), unique format structures.  The names I used for the format_labels are:  aix-ssha-1 aix-ssha-256 and aix-ssha-512.   If these need changed, that is simple, just 3 line change.

As for speeds, here is a generic build (oSSL), showing the speeds are as expected (even better).  It is just this laptop is a snail.

Benchmarking: raw-sha1, Raw SHA-1 [32/32]... DONE
Raw:    2474K c/s real, 2508K c/s virtual
Benchmarking: raw-sha256, Raw SHA-256 [32/32 OpenSSL]... DONE
Raw:    1198K c/s real, 1231K c/s virtual
Benchmarking: raw-sha512, Raw SHA-512 [32/32 OpenSSL]... DONE
Raw:    674542 c/s real, 686577 c/s virtual

Benchmarking: aix-ssha-1, AIX LPA PBKDF2-HMAC-SHA-1 [32/32]... DONE
Raw:    24032 c/s real, 24674 c/s virtual
Benchmarking: aix-ssha-256, AIX LPA PBKDF2-HMAC-SHA-256 [32/32]... DONE
Raw:    11304 c/s real, 11491 c/s virtual
Benchmarking: aix-ssha-512, AIX LPA PBKDF2-HMAC-SHA-512 [32/32]... DONE
Raw:    5447 c/s real, 5562 c/s virtual

expected timings, i.e. 1/128 raw, are:  19328, 9359, 5269, so the timings above show that we are above expectation, which  is really what we 'expect' ;)  NOTE, there is some overhead, because there is a CTX memcpy for each crypt call.  That is less overhead than the singleton overhead of the raw formats, but it is 'not' free.  In jtr_sha2 and oSSL cases, I have minimized the memcpy overhead somewhat, by not copying the CTX buffer. But that only improves things 2 or 3%.  The timings above show that improvement, since I build with oSSL.

I will get this code in to magnum to patch into git shortly.  I still want to track down some compile issues he sent me for the sha256/sha512 building under MAC and CommonCrypto.


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.