Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Mon, 19 Sep 2011 10:14:37 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: Jumbo-6

I just posted a small patch for md5-gen.  Saltless hashes were 'appearing'
to run about 150% the speed that they actually run.

 

There was a prior fix added where the actual salt_len in the format
structure was bumped up 1 byte. This fixed buffer overwrite problems, where
a null byte was overwriting buffer (valgrind found this problem).  What was
happening, was that saltless hashes were getting a salt length of 1.  I am
not fully sure of all of the implications, but it appears that normal
running was 'fine'.  The speed was right, and all passwords were found.
However, the benchmark timings were about 150% what they should have been.
This length of salt must have triggered something within the bench
code/timings.

 

The bug was found by Magnum, who noted that md5_gen(0) was 50% or so faster
than raw-md5 (which is a thin format to md5_gen(0) )

 

 

The 'correction', is very trivial.  I simply check if there is a salt_len
before incrementing it (within the init of the format).  The reason raw-md5
ran properly, is it did not copy the salt_len from the underlying md5_gen
format record.  It copied the fields which needed copied over, but not that
length.  Thus, it was still running with a salt_len of zero, so did not
exhibit the phony faster benchmark timings.

 

 

The patch is 0009-md5_gen-benchmark-problems.diff on the wiki.    Hopefully,
this will be put into the 'real' jumbo-6.

 

Jim.


Content of type "text/html" skipped

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.