[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 2 Feb 2013 19:36:28 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: NTLMv1 and MSCHAPv2 (was: NetNTLMv1)
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.
> > 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).
Alexander
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.
