Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 31 Jan 2013 07:29:05 +0100
From: atom <atom@...hcat.net>
To: john-dev@...ts.openwall.com
Subject: Re: NetNTLMv1

I never looked at NetNTLM before but yesterday some guy on hashcat
forum asked for implementation into hashcat.

This weakness was obvious to me. I was wondering why its not implemented in JtR.

You're right so far, the weakness is the third DES part. Its keyspace
is just 2^16. All you need is to Brute-Force this keyspace on CPU,
which is very fast. It takes only a few ms with OpenSSL DES on a
single core. But once you found it, you know the last 16 bit of the
MD4.

Now you running your candidates against the MD4, but you compare only
these last 2 bytes first. If they dont match, there is no need to
calculate the three DES parts, its completly eleminated. Only if it
matches you need to calculate it but chances for this is 2^16.

The speedup is so high that you an directly compare it to MD4.

On Thu, Jan 31, 2013 at 6:54 AM, Solar Designer <solar@...nwall.com> wrote:
> On Thu, Jan 31, 2013 at 09:03:00AM +0400, Solar Designer wrote:
>> I took a look.  It's the last portion of the key, not block, that
>> contains only 2 bytes.  The table can't be precomputed just once because
>> it depends on the challenge, but it can be precomputed in salt() (higher
>> memory usage)
>
> I have a quick and dirty implementation, storing the entire 512 KB table
> per salt.  (This can be lowered by storing partial DES blocks - still
> sufficient to reject most password candidates.)
>
> I'll post benchmarks and patch shortly.
>
>> or set_salt() (lower memory usage, but also lower speed).
>
> I tried this too, the speed was way too low.  We'd need to increase
> MAX_KEYS_PER_CRYPT a lot in order to go with this approach, and that
> will have performance impact on its own (keys not fitting in caches).
>
> Alexander



-- 
atom

email: atom@...hcat.net

web: http://hashcat.net/

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ