Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120624220614.GA6381@openwall.com>
Date: Mon, 25 Jun 2012 02:06:14 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Why the PHPS benchmark change from Many salts/Only one salt to Raw since jumbo-5?

Frank, all -

On Sun, Jun 24, 2012 at 11:46:46PM +0200, Frank Dittrich wrote:
> Is there a reason why the single salt / many salts case shouldn't be
> relevant anymore?

There's only one test vector in PHPS_fmt_plug.c, so the "many salts"
benchmark wouldn't be reasonable.  A recent change to bench.c recognizes
this special case now.

We need to add more test vectors.  In general, having only one test
vector is wrong, yet this is the case for many formats currently.

> For jumbo 5, there's a large difference for many salts/only one salt,

This is puzzling.  A bug?  Here's what I get with magnum-jumbo from a
few days ago, prior to the bench.c change:

Benchmarking: PHPS md5(md5($pass).$salt) [128/128 XOP intrinsics 16x4x2]... DONE
Many salts:     30907K c/s real, 30907K c/s virtual
Only one salt:  9006K c/s real, 9006K c/s virtual

And with current magnum-jumbo:

Benchmarking: PHPS md5(md5($pass).$salt) [128/128 XOP intrinsics 16x4x2]... DONE
Raw:    30619K c/s real, 30619K c/s virtual

So we're getting the better one of the two speeds now, and I think it
actually corresponds to having a fixed password, so md5($pass) probably
gets precomputed.  We really need to add more test vectors to get
reasonable benchmark results.

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.