|
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.