john-users - Re: Contributing significant changes to the jumbo patch (mostly performance improvements)

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.