Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 9 Sep 2011 07:42:47 -0500
From: "JimF" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: Re: New pkzip format

From: "Solar Designer" <solar@...nwall.com>
> On Thu, Sep 08, 2011 at 04:41:42PM -0500, jfoug wrote:
> ...
>> I know Alex wants to inflate the benchmarks sometimes, ...
>
> What are you referring to here?

What is being benchmark, is a pretty unrealistic 'raw' speed of the crypt 
function. However, that is pretty much how any crypting software will bench 
itself.  You hear of '3.6 GB / s throughput' for some crypting function, 
similar to what we see 27000K/s for some formats.  This is simply stating 
the raw speed.  There is no way to take crypt algorithm X, and ever 10.8 GB 
of data in 3s (3*3.6), even though it is rated at that speed.  This is 
simply due to additional overhead that has to be in there.   Now, in the 
algorithm was a black box on the wire, totally non affected by any IO, 
simply working it's wonder on the bytes flying through, then it is likely 
possible that the claimed speed could be met, if the pipe was large enough 
to support this.

However, in comparison of password packages, I think they are all doing 
pretty much the same thing. Trying to cut out any overhead, and simply 
testing the raw encryption speed, spinning over the cryptor.

My usage of 'inflate' may have been the wrong word chosen, and I am not 
quite sure what the right one is.  My thought behind that statement was that 
the benchmark number shown, often is considerably higher than the real world 
experiences actually running john.   At the very least, I would think we 
could provide a VERY fast way to serve up passwords, but not the same memory 
buffer or 2 over and over again, and call the crypt followed by a call to 
cmp_all, so that it actually is a little closer to real world speeds.  I 
know you are trying to keep the speeds comparable with both prior versions 
of john, and with external competing packages.  If we all of a sudden 
release a version of john that is 10% slower in benchmarks for several 
formats, then users would notice that right off, and not be happy about 
using that version, even if the true speed of the format has not changed at 
all.  It is all in perception.

> [alex] from a prior email.
>  (I haven't considered your specific proposed changes yet.)

I have no specific proposals.  What I did was a very quick/dirty hack. I was 
more interested in seeing 'why' pkzip -test was so far below, and then to 
run john in a blind test to see if there were other formats which also 
obviously being underreported by the current method of bench.   It is NOT a 
proposed change, just a demonstration.  It may be possible to simply keep 
the current behavior, and 'make it work' for the formats having problems 
with proper passwords, by smashing the correct passwords owned by the 
format, prior to starting the bench loop.  If done that way, there should be 
no impact at all on the existing formats, unless testing bad passwords takes 
longer, but then we really SHOULD know that, to try and correct that, 
because wrong passwords is the normal thing the crypt should get, and 
correct passwords is actually the anomaly. However, for the 3 formats which 
take a MUCH longer time processing correct passwords, they now would not be 
getting the right passwords, so their true throughput values would be shown.

Jim.


Powered by blists - more mailing lists

Your e-mail address:

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