Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 3 Feb 2013 11:19:15 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: NTLMv1 and MSCHAPv2 (was: NetNTLMv1)

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.

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.