[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
