Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Mon, 13 May 2013 19:30:44 +0200
From: magnum <>
To: "" <>
Subject: Incremental mode in


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

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"?


[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.