[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130203071014.GA24893@openwall.com>
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.
