[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 16 Jul 2009 14:49:41 -0500
From: "JimF" <jfoug@....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].
>
> bartavelle:
>
> I have thought about this but didn't implement ....
> 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 ...
The feature seems to be very trivial to implement. There are several
places within the code of mkv.c, where a call to crk_process_key()
is called. I simply changed all of the existing if() to be this:
if (gmin_level<=pwd.level && crk_process_key((char *)pwd.password))
It worked properly, and exactly the proper items were stored. I tested
by first doing MKV=110, then MKV=99 then MKV=100_110 (the min
and max level). Then contenated the data from 99 and 110-110 sorted
and sorted the m110 and compared. They are identical.
I also tested using start and end. I ended up with some spill over from
the end of one run, to the start of the next (i.e. a few dup passwords).
However, I tested the original MKV code, and see the same thing,
more passwords simply duplication from the end of one, to the start
of the next. I think this issue is due to tail recursion within the
show_pwd_* functions. Once they get into the code parsing the
passwords, they will stay there parsing, even if the required number
of passwords has already been generated. That should be a pretty
easy thing to fix.
But aside from that issue, adding a minimal LvL to MKV was trivial.
the longest part was getting the option parsing code added, and then
stepping the code until I found the 'proper' place to make a change.
Well with a little looking, the bug 'might' be:
gend = mkv_end + 10; /* omg !! */
Note the nice comment :)
Fixed. Had to remove that += 10, and make a few other changes to
the code, like properly checking for gidx>gend at the proper locations.
As a side note, I was able to add ETA code and also found a bug in
the xx.yy% changes I made (overflow issues when lot of rules/ppr used).
Also found that in the ETA building, I had to test, the expected ending
time value to make sure it will not be after Jan 2038, or some
implementations
will fault (my MinGW faults). In those case, I output (ETA: MANY years)
since it is not likely that run will ever complete anyway.
Jim.
--
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.
