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.