john-users - Re: Re: Inverted chatsets?

Openwall Project		/home Owl JtR Pro crypt pam_passwdqc tcb phpass scanlogd popa3d msulogin / Linux BIND / advisories presentations / services donations / wordlists passwords / news community lists wiki CVSweb mirrors signatures
bringing security into open environments

Password Recovery Resources on the Net

[<prev] [next>] [<thread-prev] [thread-next>] [month] [year] [list]

Date: Sat, 17 Jun 2006 00:11:24 +0300
From: Pietari Kivikangas <JTR1998@...l.ru>
To: john-users@...ts.openwall.com
Subject: Re:  Re: Inverted chatsets?

Phantom wrote:
> Well, I don't wanna wait 5 years, if I could potetially get them in 2 weeks by
>  using reversed frequency tables;)
>   
When the rec_entry variable in the module inc.c (in .rec file produced 
by John The Ripper version 1.7 it is stored at the 11th position from 
the end of file, the following numbers are 0 and 8) reaches the range of 
values 3000-3419, the probability of the next password candidate being 
the password you are looking for floats in the range between 
1/0x00003afa8baa2780LL and 1/0x00000057cfdce769LL. Therefore, from 
statistical point of view there is definitely no reason to suppose that 
you find the right password "in 2 weeks".

>> By definition, a charset file inverted to the original one is such 
>> charset which can be used to produce ALL password candidates EXCEPT for 
>> those which can be produced using the original charset file.
>>     
>
> Again, this doesn't make sense to me...
> Correct me if I'm wrong, but given that the passwords are "only" using the 95 
> normal chars, wouldn't all.chr (with normal frequncy tables) also eventually 
> find all the passwords? 
>   
Yes, all possible candidates will be produced and tried against the 
hash(es). Thus the inverted charset file being in question would be used 
to produce NO candidates.