[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 17 Jun 2006 04:17:37 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Re: Inverted chatsets?
On Fri, Jun 16, 2006 at 07:28:40PM +0000, Phantom wrote:
> Solar Designer <solar@...> writes:
> > Of course, chances are that we won't get any passwords cracked in any
> > reasonable amount of time in this way.
>
> Well, I still say it would be worth testing :)
You're free to waste your own time on that. ;-)
> Since there must be some passwords, where doing it "backwards" would be faster
> than the normal way...?
Yes, there must be such passwords - but they are very uncommon. For
example, the last 5 passwords that JtR 1.7 would try with its default
all.chr are -
}}}}}`<`
}}}}}`"`
}}}}}`\`
}}}}}```
}}}}}`|`
> Then, it might be beneficial to be able to start -i:all from a certain point,
> further on in the frequency "tables" - something like skip the first 10 mill
> most likely combination and start from there instead?
This has been suggested to me (via private e-mail) many times. I don't
think that this is such a great idea, except in some rare special cases
(e.g., when you know that you've run -i=all with the same all.chr file
for a certain amount of time at a certain candidate password per second
rate in the past, but have lost your .rec file).
> I find it hard to figure out how the .rec files are built and how,
> if possible, one could edit a .reito make it jump past some combinations
> and start from somewhere else...
This is possible, but I don't want to make it any easier to do because
most of the time it is a wrong thing to do.
If you want to skip just 1 million of candidate passwords, the easiest
and most reliable way to do so is by using a filter() to skip those
passwords initially. Then you can interrupt and recover the session
without the filter() to not waste any more processing time on the
filtering.
--
Alexander Peslyak <solar at openwall.com>
GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 B35D 3598
http://www.openwall.com - bringing security into open computing environments
Powered by blists - more mailing lists
Powered by Openwall GNU/*/Linux -
Powered by OpenVZ
