[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120628203613.GA25058@openwall.com>
Date: Fri, 29 Jun 2012 00:36:13 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Is saving 2 bytes per salt worth the effort?
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. 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?
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().
Alexander
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.
