Date: Thu, 8 Sep 2011 16:41:42 -0500 From: "jfoug" <jfoug@....net> To: <john-dev@...ts.openwall.com> Subject: RE: New pkzip format [Moved to 'onlist' ] I put it there, with 2 (pretty long winded) emails. I think I have stated the symptoms. You are 100% correct. The bench simply spins over crypt() passing in valid passwords. A much better benchmark would be to generate 10k passwords from alnum (or just generate 10k 'random' alnum 6, 7 and 8 byte strings, removing any longer ones if the format cannot handle them that long), and then pass those into the format, always calling the set_keys for single salt, and not calling them for multi-salt, and then calling cmp_all/cmp_one/cmp_exact just like the format would do. I know Alex wants to inflate the benchmarks sometimes, and IF we change how a version shows benchmarks, users would scream if all of a sudden they are comparing apples to oranges, and timings of their favorite format all of a sudden drops from 8000k to 6700k (even though the format is running exactly as fast between the 2 versions). This might almost need to be a format change. Have a field listing bench algorithm used. 0 would be the legacy algorithm (spin on crypt with correct password). 1 could be to use a more realistic algo, etc. That way, most of the formats could be left along, but if there ARE formats which have a huge disparity between good and bad passwords (pdf, and some of the other formats also have the same issue, IIRC), then these formats could set this value to a 1, and thus, bench would use the 'new/better' algo, while not giving the long time users of JtR a bad taste about a 'slow' version. Jim. >-----Original Message----- >From: magnum [mailto:rawsmooth@...dband.net] > >I think I can guess the problem: The benchmark don't do the normal >"chain" of crypt_all(), cmp_all() etc. when it tests speed. It just >calls crypt_all() a number of times (for one-salt). The way your format >is made now it gets unreasonably low figures. You could possibly get the >opposite false figures (extreme speed) with a crypt_all() that just >returns, and *all* logic in cmp_*() ... > >Take it do john-dev, maybe Solar has a good solution (or fix for John >core).
Powered by blists - more mailing lists
Powered by Openwall GNU/*/Linux - Powered by OpenVZ