Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 23 Jun 2015 08:13:23 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Interleaving of intrinsics

On Tue, Jun 23, 2015 at 02:44:52AM +0200, magnum wrote:
> On 2015-06-22 21:48, Solar Designer wrote:
> >On Mon, Jun 22, 2015 at 09:40:55PM +0200, magnum wrote:
> >>As Lei wrote, all speeds for PBKDB2-HMAC
> >
> >Where?  I must have missed that.
> 
> It was clearly stated (although he omitted number of iterations) but 
> PBKDF2-HMAC-MD4/5 formats are so unintuitive your brain might have 
> refused to take it in :-)

Oh, I found it now - "We're using all PBKDF2-HMAC formats here".

> >>(yes, even MD4 and MD5). All of
> >>them are c/s for 1000 iterations. So 737882 c/s corresponds to something
> >>like 737882 * 2002 = 1.4G hashes per second. I'm not sure that makes
> >>sense on a MIC but that's what it should mean.
> >
> >Oh.  It makes sense, yes.  And it was worthy of benchmarking and
> >considering for tuning of the interleaving factors, then.
> 
> That's what I thought when adding pbkdf2-hmac-md4 which is a totally 
> useless format otherwise, not likely used anywhere IRL. We can now 
> benchmark MD4 figures without bottlenecks. The format was obviously very 
> trivial to add, more or less cp & sed. BTW I have added both of these 
> formats for OpenCL too, for the same reasons. Super trivial, and great 
> for benchmarking the raw hash code.

Yes, this was a good idea.

> BTW maybe we should add test vectors with 499 iterations... 
> that way you could actually read the c/s figures as "K hash/s" :-)

No, I think 1000 iterations is fine.

Even at 499, those speeds wouldn't exactly correspond to what's possible
for non-iterated hashes, because in those cases some steps can be omitted.

Alexander

Powered by blists - more mailing lists

Your e-mail address:

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