Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Mon, 6 May 2013 21:24:11 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: Enhancements to pbkdf2-sha256

[was offlist]

Here is a VERY early test (only sha1 and sha256 done).  This shows just HOW
piss ass SLLLLOOOOOOWWWW using the 'correct' oSSL pbkdf2 code is, vs the way
I did it back in the mscash2 conversion ;)   Now, the joy of the new code,
is patching it into this format is only a couple lines changed in a couple
places in the file, and it works right off the bat, woohoo!

$ ../run/john -test=5 -form=aix-ssha
Benchmarking: aix-ssha, AIX LPA PBKDF2-HMAC-SHA-1 / SHA-2 [32/32]... DONE
Raw:    4629 c/s real, 4733 c/s virtual

$ ../run/john -test=5 -form=aix-ssha
Benchmarking: aix-ssha, AIX LPA PBKDF2-HMAC-SHA-1 / SHA-2 [32/32]... DONE
Raw:    23831 c/s real, 24317 c/s virtual

That is a 5x improvement, by simply not using the 'official/correct'
PKCS5_PBKDF2_HMAC() function.  

I 'should' have pbkdf2_hmac_sha512 working for oSSL, but I have not tried it
yet.  It will not have working code for SSE2 (yet), since I have not ported
that crypt into sse-intrinsics.c yet, but that is on my todo-soon list.

Jim.

-----Original Message-----
From: magnum [mailto:john.magnum@...hmail.com] 
Sent: Monday, May 06, 2013 19:22
To: jfoug@....net
Subject: Re: Enhancements to pbkdf2-sha256

aix-ssha has pbkdf2-hmac-sha1/256/512. That one would be great.

magnum


On 7 May, 2013, at 0:58 , jfoug@....net wrote:

> I have enhanced pbkdf2-sha256 to be 'like' the sha1 variant.
> 
> Includes:
> 
> 1. multiple hashes (so we can get 128 bytes of pbkdf2 hash if needed).
> 2. the skip bytes interface (like in zip).
> 3. PARA should work, when/if implemented, for sha256.
> 
> Are there any other hash types, that we should do CPU pbkdf2 for?  It
would be nice to have a consistant interface, where each type is simply a
single include, and then a 1 (or several) line call to the code, BUT where
it runs as fast as any 'hand' coded algo.   It would save 100 or many more
lines in each file, vs replicating that code everywhere.  Hell, look at
cash2.  I bet that is 400 or 500 lines of code, that could be replaced by 10
or so, with no loss of speed (and possibly an increase, since there are some
additional optimizations learned since I did that code).
> 
> Jim.<JtR-bleeding-pbkdf2-256-upgrade.patch>


Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ