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.