Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 1 Feb 2013 07:45:12 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: NetNTLMv1

On Thu, Jan 31, 2013 at 07:59:52AM +0400, Solar Designer wrote:
> We could switch to using JtR's faster NTLM code, and bitslice DES code
> for the DES portion.  This would probably provide speeds similar to
> hashcat's on that screenshot (76M c/s for NetNTLMv1 on one CPU chip), or
> maybe even better.  (Looks like JtR's NTLM provides 22.6*8 = ~181M c/s
> on FX-8120 - that's --test speeds combined for 8 independent processes.
> Of course, actual cracking speed will be less.)

I am now getting 21.3*8 = ~170M c/s at NetNTLM, combined for 8
independent processes on FX-8120.  Of course, this is cumbersome to use
(until we get --fork support in).

At "many salts" benchmark (where "many" means BENCHMARK_MANY in
params.h, which is 0x100), the combined speed is 470*8 = 3760M c/s.
That's for XOP builds.

With a generic+OpenMP build, it is ~3150M c/s for one process (8
threads).  This puzzles me, because generic's MD4 computations are
slower, whereas the comparisons are not supposed to be faster since
OpenMP is only being made use of for the MD4s, not for comparisons, in
that code version.  So I would have expected its performance to be
around ~850M at "many salts" - same as I'm getting for one process with
the XOP build (on otherwise idle system).  I don't understand where a
further 4x speedup comes from.

Alexander

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ