[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 7 May 2013 9:18:38 -0400
From: <jfoug@....net>
To: john-dev@...ts.openwall.com
Subject: Re: Enhancements to pbkdf2-sha256
---- Solar Designer <solar@...nwall.com> 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.
Jim.
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.
