|
Message-ID: <20130201034512.GA18686@openwall.com> 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
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.