Follow @Openwall on Twitter for new release announcements and other news
[<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

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.