Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Thu, 11 Jun 2015 10:32:19 +0200
From: Frank Dittrich <frank.dittrich@...lbox.org>
To: john-users@...ts.openwall.com
Subject: PRINCE mode: sequence of generated passwords

I just did a simple PRINCE mode test.

(bleeding-jumbo)run $ ./john --stdout --prince 2> /dev/null|head -n 20
mememe
22meme
aameme
gomeme
me22me
2222me
aa22me
go22me
meaame
22aame
aaaame
goaame
megome
22gome
aagome
gogome
meme22
22me22
aame22
gome22

Looks like PRINCE mode started combining 'me', '22', 'aa', and 'go'.

For a wordlist which is not sorted by probability, this is probably
fine, even though I wonder why john didn't try combinations of two of
these words first.
But passwords.lst is sorted by probability, and there are many words
which are more likely then those picked for the first candidates.


(bleeding-jumbo)run $ ./john --stdout --wordlist=password.lst 2>
/dev/null |grep -v "^$"|grep -n -E "^(me|22|aa|go)$"
959:me
3343:22
3494:aa
3541:go

The first two password candidates in password.list are 12345 and 123456.
The combination of these two will only be tried after more than 500
million other candidates (even more than 100 million candidates of
length >= 11:

(bleeding-jumbo)run $ ./john --stdout --prince 2> /dev/null|grep -n
"^12345123456$"
518456277:12345123456
(bleeding-jumbo)run $ ./john --stdout --prince --min-length=11 2>
/dev/null|grep -n "^12345123456$"
165728577:12345123456


I think this is very unfortunate.

How hard would it be to implement another sequence (controlled by an
additional --prince-* option)?
The alternative sequence should assume that words on top of the password
list are more likely.

There might be different algorithms.

A simple one would just generate the passwords for
$ ./john --prince --prince-wl-max=1
Then, the passwords for
$ ./john --prince --prince-wl-max=2
and so on, but without repeating the candidates that have been produced
earlier.

So, in this new mode, john should only start producing combinations that
include a word in position N after all combinations of words up to
position N-1 have been tried.


Another alternative would assign a weight to each word (depending on the
position in the word list), and then generate the sequence according to
the total weight (e.g., the sum of weight of each word).
This might be harder to implement efficiently, but would prefer
combinations of two words over combinations of three words.


Frank

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.