|
Message-ID: <20130207035601.GA30949@openwall.com> 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.