[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 8 Sep 2011 17:21:43 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: RE: New pkzip format [Moved to 'onlist' ]
It appears there are 2 other formats which are getting artificially low
numbers by always using the 'correct' password. Of course, they are
'similar' to pkzip, and that they are more of an encryption, vs a true
password hashing. These formats are ssh, and pdf. They are not nearly as
large of an impact as pkzip was, but the bench certainly is under
representing them:
Original 1.7.8-jumbo-6 timings:
Benchmarking: ssh [32/32]... DONE
Raw: 69223 c/s
Benchmarking: pdf [32/32]... DONE
Many salts: 10185 c/s
Only one salt: 16699 c/s
Using my crappy hack in bench.c, to not use the correct passwords:
Benchmarking: ssh [32/32]... DONE
Raw: 136849 c/s
Benchmarking: pdf [32/32]... DONE
Many salts: 13970 c/s
Only one salt: 30034 c/s
The code does slow things down. There is a lot more seen in the '1 salt'
testing, due to many more calls to set_key(), and each one of those now
performing a strcpy, but again, my changes to bench.c is a 2 minute hack,
and not how it really should be done.
But the above shows that pkzip format is not the only one which the existing
benchmark algorithm is under representing the true speed.
Jim.
>From: magnum [mailto:rawsmooth@...dband.net]
>
>On 2011-09-08 23:41, jfoug wrote:
>> 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.
>
>Well we already have BENCHMARK_LENGTH (I don't get why it's called that)
>of 0 or -1 so why not just add a couple more possible values there?
>
>magnum
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.
