Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 16 Jul 2009 14:49:41 -0500
From: "JimF" <>
To: <>
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 
will fault (my MinGW faults).   In those case, I output (ETA: MANY years)
since it is not likely that run will ever complete anyway.


To unsubscribe, e-mail 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.