Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 3 Feb 2013 11:10:14 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: NetNTLMv1

On Sun, Feb 03, 2013 at 03:01:54AM +0100, magnum wrote:
> Lol, I hit a luxury problem:

I fully expected you would. :-)

> Benchmarking: NTLMv1 C/R MD4 DES (ESS MD5) [128/128 SSE2 intrinsics 12x]... DONE
> Many salts:	4294M c/s real, 4294M c/s virtual
> Only one salt:	38731K c/s real, 38348K c/s virtual
> 
> 
> I can't tune BLOCK_LOOPS,

Besides tuning BLOCK_LOOPS, you may also try re-enabling the memset()
approach to cleaning the bitmap in crypt_all() when max_keys_per_crypt
is known to be large enough at compile time.

> because I hit the 32 bit limit and always see 4294M. I am pretty sure I fixed this for MPI, maybe we should always use the MPI version of that code in bench.c.

I haven't looked into this yet.  I think you'll take care of it. ;-)

And yes, we had faced this first world problem before, with MPI and fast
hashes.  Somehow it was not (yet?) addressed for MPI when we got 384-way
benchmarks last summer:

http://openwall.info/wiki/john/benchmarks#Collected-john-test-benchmarks-for-MPI-enabled-builds

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.