|
Message-ID: <20150623051323.GA21313@openwall.com> 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
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.