Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130131093748.GA10997@openwall.com>
Date: Thu, 31 Jan 2013 13:37:48 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: NetNTLMv1

magnum, all -

On Thu, Jan 31, 2013 at 07:29:05AM +0100, atom wrote:
> 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.

Attached is quick and still dirty implementation of the above approach
for JtR.  Compared to the approach with maintaining a lookup table per
challenge, this has lower memory needs and higher cracking speed, but
(as currently implemented) it does the ~32k DES computations per C/R
pair rather than per challenge.  It is possible to improve it to only do
those computations per challenge, by temporarily maintaining a lookup
table for each challenge (during loading only, and maybe only for the
current challenge).

New speeds:

Benchmarking: NTLMv1 C/R MD4 DES (ESS MD5) [32/64]... DONE
Many salts:     882291K c/s real, 882291K c/s virtual
Only one salt:  7647K c/s real, 7647K c/s virtual

Benchmarking: NTLMv1 C/R MD4 DES (ESS MD5) [32/64]... (8xOMP) DONE
Many salts:     910901K c/s real, 114005K c/s virtual
Only one salt:  13025K c/s real, 1626K c/s virtual

Alexander

View attachment "john-NETNTLM-undes.diff" of type "text/plain" (7308 bytes)

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.