Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Thu, 31 Jan 2013 07:59:52 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: NetNTLMv1

magnum, all -

Since I think you're not on Twitter:

TTYtter> /th c9
zz0> (x13) <hashcat> Exploited a NetNTLMv1 weakness which made it as easy to crack as NTLM: http://t.co/Sul7VK1p - No, this is not what CloudCracker does
zz1> <@...rsheim> @hashcat Another weakness first discovered by you? ;-)\n(if so; @dangoodin001 ...)
zz2> <@...hcat> @thorsheim @dangoodin001 I discovered it myself and afterwards found it on jtr mailinglist. They never made any use of it /cc @solardiz
zz3> <@...rsheim> @hashcat Perhaps a forum post on its implications? Speed improvements etc? / @solardiz
zz4> <@...hcat> @thorsheim @solardiz Yeah why not. Will do it once I ported it to GPU. It will be far far to fast for such an important algorithm :-)

I'm not sure what exactly atom is referring to.  There's definitely lots
of room for optimization of the code in JtR:

http://www.openwall.com/lists/john-dev/2011/04/17/1

We could switch to using JtR's faster NTLM code, and bitslice DES code
for the DES portion.  This would probably provide speeds similar to
hashcat's on that screenshot (76M c/s for NetNTLMv1 on one CPU chip), or
maybe even better.  (Looks like JtR's NTLM provides 22.6*8 = ~181M c/s
on FX-8120 - that's --test speeds combined for 8 independent processes.
Of course, actual cracking speed will be less.)

However, maybe atom somehow reduced or eliminated the DES portion from
the per-candidate loop, as I doubt he went for bitslice DES here. ;-)

Curious.

Oh, here's an idea: what if we apply the DES encryption (or decryption)
to the last of the 3 blocks, not the first?  Doesn't the last block
contain only like a couple of non-zero bytes?  (I don't recall.)  If so,
we could replace this instance of DES with a lookup table, computed just
once (e.g. at program startup, to avoid increasing program size).

Is this it?  Was it mentioned on our mailing lists before?  Maybe in the
2007 discussion with jmk, in rainbow tables context?

Alexander

Powered by blists - more mailing lists

Your e-mail address:

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