Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ