Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 2 Feb 2013 21:06:42 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: NTLMv1 and MSCHAPv2 (was: NetNTLMv1)

On 2 Feb, 2013, at 16:36 , Solar Designer <solar@...nwall.com> wrote:
> On Fri, Feb 01, 2013 at 07:48:15PM +0100, magnum wrote:
>> On 1 Feb, 2013, at 18:22 , Solar Designer <solar@...nwall.com> wrote:
>>> Should we possibly print a warning when we determine that the number of
>>> C/R pairs is 100 or larger?  Should we provide an alternative mode -
>>> like the code we had before? some way to invoke John to crack the 3rd
>>> DES blocks only and record the 16-bit results for reuse by subsequent
>>> invocations?
>> 
>> You mean reverting to v1 of the optimization, right?
> 
> No, in v1 (the one with lookup tables?) startup could still be slow if
> the number of different challenges is large.  So it isn't a complete fix
> for the slow startup issue.  By "the code we had before" I meant jumbo-7.

I had the idea the v1 table was created in set_salt() but I remember now that did not work well.
But the J7 code is 320x slower for 256 salts (iirc the many salts figure), isn't it? Should we revert to slower code as soon as we get a wonderful chance to use the faster? What do I fail to see here?


>>> Another concern: when the number of responses per challenge is very
>>> large, these optimizations may actually be slowing things down, because
>>> we're no longer providing hash functions with larger than 16-bit output.
>>> Is it realistic that someone would have millions of responses for the
>>> same challenge?  Perhaps if a fixed challenge is provided in an active
>>> attack?
>> 
>> The table lookup version would be better in this case too.
> 
> No, it would actually be slightly worse.  Its get_hash*() provide at
> most 2^16 different values (for a given challenge), with get_hash_3()
> specifically providing 63% of that figure (if I recall and understand
> correctly - I did not actually test this).

True. Well, I don't think I'm going to dig into this unless someone actually claims he needs it.

magnum

Powered by blists - more mailing lists

Your e-mail address:

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