[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 7 Feb 2013 07:56:01 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: NetNTLMv1 and MSCHAPv2
magnum -
On Thu, Feb 07, 2013 at 01:42:11AM +0100, magnum wrote:
> I noticed the formats are significantly faster in unstable than in bleeding, with 1500 c/r real (Test Suite) runs:
[...]
> That's 12.5%. For NTLMv1, it's even worse: 8760M vs. 10402M or 18.7%. It's not a general issue, NT does have a slight regression too but nowhere near this much. I assume this is some unfortunate effect of bleeding's bitmap and changed hash tables sizes? Maybe a number of factors just happen to line up with bad luck here?
Perhaps some difference in memory layout in the specific builds, yes.
It is weird that you're seeing a regression even for NT, though. The
bitmaps were supposed to make things faster (and they did in my initial
testing, with LM hashes in core), not slower. We'll need to revisit
this before bleeding turns into a new jumbo release (after that happens
to unstable first).
As to speeding up NetNTLMv1 and MSCHAPv2 some more, if we care, we may
want to split the crypt_key[] array in two, one for 2-byte "hot"
portions of the output and the other for 14-byte "cold" portions (may
expand them to 16 bytes for faster index to offset calculation).
Allocating 21 or 22 bytes wastes cache space. We only use 21 in
cmp_exact(), for one hash at a time - we could use a local variable
there instead. I am not going to work on this now. You may. :-)
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.
