Date: Sun, 28 Jan 2007 11:58:59 +0100 From: "Frank Dittrich" <frank_dittrich@...mail.com> To: john-users@...ts.openwall.com Subject: Re: how to find a password of 16 digits Solar Designer wrote: -- frank_dittrich@...mail.com >From: Solar Designer <solar@...nwall.com> >Reply-To: john-users@...ts.openwall.com >To: john-users@...ts.openwall.com >Subject: Re: [john-users] how to find a password of 16 digits >Date: Sun, 28 Jan 2007 10:11:11 +0300 >MIME-Version: 1.0 >And generate a new .chr file: > > cd ../run > ./john --make-charset=digits16.chr > [...] >Now you can define a new "incremental" mode: > >[Incremental:Digits16] >File = $JOHN/digits16.chr >MinLen = 16 >MaxLen = 16 >CharCount = 10 > >Note that this new digits16.chr will also work for lengths 0 to 15, if >you ever need that. Why do you need a new chr file? Wouldn't the original digits.chr file work as well (or a poorly, for that matter)? Not that I think trying all password sequentially is any better. But I doubt you gathered any useful statistical information for 16 digit "passwords". I didn't recompile JtR for incremental mode with length 16, but your example looks like John tries 2222222222222222, then all passwords containing just the digits 2 and 4 (and at least one digit 4), then all passwords containing at least one digit 0 and only digits 2, 4, and 0, and so on. You should get similar results by just recompiling JtR, and using the original digits.chr file [Incremental:Digits16] File = $JOHN/digits.chr MinLen = 16 MaxLen = 16 CharCount = 10 The only difference is the somewhat different character frequency and frequency of character combinations in the john.pot file generated according to your suggestion, compared to the john.pot file that has been used to generate the original digits.chr file. You can reproduce this behaviour without recompiling john. Just assume you want to crack case insensitive passwords of length 8. There's no suitable .chr file, so you could use: [Incremental:lanman8] File = $JOHN/lanman.chr MinLen = 8 MaxLen = 8 CharCount = 69 Or, you could generate a dummy john.pot file (BTW: make sure you don't accidently overwrite an existing john.pot file you might still need) ./john -i=lanman --stdout | sed 's/^/:/; 1000000q' > john.pot generate a new .chr file ./john --make-charset=lanman8.chr and define a section [Incremental:myy_lanman8] File = $JOHN/lanman8.chr MinLen = 8 MaxLen = 8 CharCount = 69 Now, both ./john -i=lanman8 --stdout|head and ./john -i=my_lanman8 --stdout|head produce the same output: ./john -i=lanman8 --stdout|head There's, however a difference. ./john -i=lanman8 --stdout | grep -n -C 3 "[^AE]"|head 254-AAAAAAEA 255-AAAAAAEE 256-AAAAAAAE 257:RAAAAAAA 258:RAAAAAAE 259:RAAAAAAR 260:RAAAAAEA 261:RAAAAAEE 262:RAAAAAER 263:RAAAAARA vs. ./john -i=my_lanman8 --stdout | grep -n -C 3 "[^AE]"|head 254-AAAAAAEA 255-AAAAAAEE 256-AAAAAAAE 257:SAAAAAAA 258:SAAAAAAE 259:SAAAAAAS 260:SAAAAAEA 261:SAAAAAEE 262:SAAAAAES 263:SAAAAASA And: ./john -i=lanman8 --stdout | grep -n -C 3 "[^AER]"|head 6559-EEEEEAER 6560-EEEEEEAR 6561-EEEEEEER 6562:OAAAAAAA 6563:OAAAAAAE 6564:OAAAAAAR 6565:OAAAAAAO 6566:OAAAAAEA 6567:OAAAAAEE 6568:OAAAAAER vs. ./john -i=my_lanman8 --stdout | grep -n -C 3 "[^AES]"|head 6559-EEEEEAES 6560-EEEEEEAS 6561-EEEEEEES 6562:OAAAAAAA 6563:OAAAAAAE 6564:OAAAAAAS 6565:OAAAAAAO 6566:OAAAAAEA 6567:OAAAAAEE 6568:OAAAAAES In my_lanman8.chr, letter R has a higher probability than letter O (and, among others, letter S), while in lanman.chr, letter S has a higher probability than letter O (and, among others, letter R). But, in both cases, prior to generating any password which contains a new letter, john first generates all passwords containing only characters which have been used in passwords generated earlier. Passwords up to number 1**8 contasin just 1 character (obviously), all passwords up to number 2**8 contain just 2 different characters, all passwords up to 3**8 (6561) contain just 3 different characters, all passwords up to 4**8 (65536) contain just 4 different characters. For the 16 digits example, that means, the first password which doesn't contain just the 2 most probable digits (2 amd 4, in our case), is password number 2**16 + 1 = 65537, the first password containing any other character than 2, 4, and 0, will be password number 3**16 + 1 = 43046722. IMO this proves that such statistical information from shorter passwords is of limited use for longer passwords. I just want to mention this to emphasize that, without additional knowledge about the password, you shouldn't hope to find the correct password easily, no matter what method you use, because the key space of 16 digit passwords is larger than the key space of DES passwords (up to 8 characters, with CharCount 95). Regards, Frank _________________________________________________________________ Don't just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ -- To unsubscribe, e-mail john-users-unsubscribe@...ts.openwall.com and reply to the automated confirmation request that will be sent to you.
Powered by blists - more mailing lists
Powered by Openwall GNU/*/Linux - Powered by OpenVZ