[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A5DEE85.60308@banquise.net>
Date: Wed, 15 Jul 2009 16:58:13 +0200
From: bartavelle@...quise.net
To: john-users@...ts.openwall.com
Subject: Re: Contributing significant changes to the jumbo patch
(mostly performance improvements)
JimF a écrit :
> One other idea I have, is to change markov to allow a range [min ..
> max]. Thus, you could run up to 220, then later pick up the search, and
> run from 221 to 240, and only end up with the 'new' material, assuming
> you use the same statsfile. Right now, about the only way to 'resume',
> is to drop both levels out to flat files (using --stdout), and then
> write code to strip the lines out of the larger file from the smaller
> one. But changing the markov processing to not output or use values
> that are under a certain threshold should not be hard at all.
I have thought about this but didn't implement it as I have no real
usage of this feature. I usually am in a situation where I run fast
tests, such as -single -wordlist and small markov values. This is mainly
used during an actual pentest. Once it is over, I run the "serious"
cracking in order to produce shiny graphs, but I know beforehand how
long I want it to run (the time it will take to write most of the
report), and will not run a subsequent job.
Moreover, implementing this feature is not that straightforward because
it must be compatible with the start/end parameters if you want to
distribute the load. It should not be too complicated however ...
--
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
