|
Message-ID: <022a01cc6e75$b0c23b90$1246b2b0$@net> 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.