[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 5 Feb 2013 20:24:40 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: NTLMv1 and MSCHAPv2
On 3 Feb, 2013, at 8:19 , Solar Designer <solar@...nwall.com> wrote:
> On Sat, Feb 02, 2013 at 09:06:42PM +0100, magnum wrote:
>> 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?
>
> We definitely shouldn't revert to the slower code unconditionally, but
> it might make sense to keep it as a non-default option (separate formats?
> netntlm-dumb and mschapv2-dumb? producing the exact same pot entries).
> The warning printed when the C/R pair number is large should mention how
> to invoke this non-default mode.
>
> In some cases the startup time could be more important than c/s rate -
> e.g., for initial processing of a very large number of C/R pairs, to
> test the weakest passwords against them (e.g., just RockYou). Then run
> the higher c/s rate mode on what remains.
Sure thing, somehow I misread what you wrote. This is now fixed, threshold is 100 c/r pairs and this is printed:
netntlm: Note: slow loading. For short runs, try netntlm-naive instead (using
--format=netntlm-naive). That version loads faster but runs slower.
MSCHAPv2 got the same fixes too.
magnum
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.
