[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20100314191248.GB20565@openwall.com>
Date: Sun, 14 Mar 2010 22:12:48 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
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, websiteaccess@...il.com 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
diminishes.
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.
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.
