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
Powered by Openwall GNU/*/Linux - Powered by OpenVZ