[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <022001cc6e70$1987bb60$4c973220$@net>
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
