[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <43b133c95afd834195a11239627ec8c1@smtp.hushmail.com>
Date: Mon, 13 May 2013 19:30:44 +0200
From: magnum <john.magnum@...hmail.com>
To: "john-dev@...ts.openwall.com" <john-dev@...ts.openwall.com>
Subject: Incremental mode in 1.7.9.14
Solar,
The following should apply to core even if tested in bleeding. The -max-len option is exactly the same as having MaxLen in john.conf for an Incremental mode.
I did this:
$ ../run/john -inc -stdout -max-len=1 | cat -n
From the output I see the least probable starting letter[1] is upper-case 'X', at #75 of 96 (including the zero length candidate).
Dropping the -max-length option (for my default of 8):
$ ../run/john -inc:all -stdout | grep -nm1 '^X$'
Press Ctrl-C or 'q' to abort, almost any other key for status
1708341975:X
That's over 5x more candidates than exhausting length 0-6 of ASCII. For a slow hash, this password will never be cracked by Incremental despite being just a single ASCII letter.
Doing the same with 1.7.9 (actually current unstable), I get 'Q' as least probable letter[2], at #74. With no length limit, it finds "Q" in 33441 tries. That is a whole lot better. Even the least probable character, '}' at #96, is found in 33463 tries with no length limit.
I had similar results with two-character candidates and so on. Is there any way short lengths could get more "weight", or some other mitigation for this "regression"?
magnum
[1] I do not think this is relevant but anyway: all.chr here is made from rockyou, only filtered for ASCII-only.
[2] This is with same all.chr as core 1.7.9.
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.
