Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 14 Mar 2010 22:12:48 +0300
From: Solar Designer <>
Subject: Re: cracking speed promised and reality

On Fri, Mar 12, 2010 at 12:38:17AM +0100, Simon Marechal wrote:
> Le 11/03/2010 09:20, a ?crit :
> >  I did a ./john -test with the latest version 1.7.5

Obviously, W.A. ran this test on something other than the 1.7.5 release.
I'd appreciate it if W.A. and others include the full version numbers,
including those of any patches.

> >Benchmarking: Raw MD5 SSE2 [raw-md5 SSE2 16x4]... DONE
> >Raw:	36842K c/s real, 36477K c/s virtual
> The -test stats do not take into account the overhead of candidate 
> passwords generation. As this cipher is really fast, this overhead 
> matters a lot,

That's correct.

> and explains the disappointing performances.

No, it does not.  On a modern CPU, the "incremental" mode generates
something on the order of 100M candidate passwords per second (when
there are no length switches).  If the cipher does 36M c/s, then the
combined c/s rate should be around 27M c/s - not the 10M c/s that W.A.
observed.  Indeed, there were length switches, which explains the much
lower c/s rate early on, but by 10 minutes the c/s rate should have
gotten much closer to 27M as the length switches become infrequent and
the effect of them having been more frequent in the beginning

So W.A.'s posting does highlight some unexpected bottleneck, but I'm not
sure which one.  Maybe my guess regarding gcc optimization flags getting
lost on some MPI builds applies.  W.A.'s output from his JtR run shows
that this was in fact an MPI-enabled build.

W.A. - I suggest that you repeat the test on a non-MPI build.


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.