Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 7 Feb 2013 08:02:07 +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 07:56:01AM +0400, Solar Designer wrote:
> 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. :-)

Taking this a step further, we could store just a few bytes of the
14-byte portion, and recompute the rest of the NT hash in cmp_exact()
when we have to.

... and if we store e.g. just last 4 bytes of each NT hash, then we can
get away with using just one array, like we do now.  2 bytes of each
element will be directly compared to the known values for the 3rd DES
block key, and 2 bytes before those last 2 will be compared to results
of DES encryption of the 2nd block, which are computed as needed.
I think I like this option best.  Separating the hot/cold arrays has
some cost of its own, and we can avoid that by simply making each
element this small (only 4 bytes).  The index to offset calculation
becomes trivial (and supported in x86's addressing modes natively).

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.