[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 28 Jun 2012 22:51:18 +0200
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Is saving 2 bytes per salt worth the effort?
On 06/28/2012 10:36 PM, Solar Designer wrote:
> On Thu, Jun 28, 2012 at 01:26:58AM +0200, Frank Dittrich wrote:
>> But when processing a large number of hashes, saving 2 or even more
>> bytes per salt might be a good idea.
>
> Yes.
>
> BTW, I am more concerned about various unused fields and padding
> inserted by the compiler into salt structs potentially resulting in
> instances of the same salt value appearing as different salts to the
> loader.
Yes, this is a possibility I completely forgot.
> For example, with the 18 vs. 16-byte thing you mentioned, what
> if there's an "overrun" into the last 2 bytes of the temporary buffer
> for one decoded salt, but then further ones are purely 16 bytes again?
For this format this shouldn't happen.
The salt is always 16 bytes long.
It is just the base64_decode function which needs a buffer of size 18
for a base64 encoded salt of length 24, even if the last 2 characters
are always "==".
> Would this possibly cause a 16-byte salt value seen early not to match
> the same 16-byte value seen later (because the extra 2 bytes may be
> stale, and different from the initial allocation vs. the "overrun").
> Even if this is not possible in this case, we should watch out for
> issues like that in general. Maybe memset() the entire struct to 0 at
> the beginning of salt().
Or even, memset the entire salt with different values for repeated tests
with the same salt/hash before calling the format specific functions,
and FAIL if the salt differs afterwards?
But that could produce false positives which wouldn't really matter in
the implementation.
Such a functionality depending on a DEBUG switch could help.
Frank
Frank
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.
