|
Message-ID: <c669135e1a70763e17bdb5e788fc022a@smtp.hushmail.com> 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.