|
Message-ID: <20140706073528.GA9205@openwall.com> Date: Sun, 6 Jul 2014 11:35:28 +0400 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: Salt dupe removal logic and format changes (Comments wanted) On Sun, Jul 06, 2014 at 12:51:11AM +0200, magnum wrote: > Not sure why this was moved here from john-dev but anyways, Jim started this thread on john-users right away. I agree that it's probably john-dev material since we're discussing source code changes in some detail. > On 2014-07-05 15:40, Solar Designer wrote: > >Here's another idea: add a new FMT_SALT_STRUCT flag that would indicate > >that the "binary salt" as used by the format is actually of a specific > >struct type containing a pointer to the actual salt value and a size > >(just these two fields, so it's 16 bytes on a 64-bit arch). When the > >flag is set, memcmp() would be called after the extra pointer > >dereference and using the actual salt size read from that struct. With > >this approach, you don't need to make any changes to existing formats. > >You start to use this new feature in formats that need it, one by one. > > I really like this idea, for being KISS and easy to experiment with. I'd > vote for trying this first. Great. Here's yet another idea: instead of the above, have a flag like FMT_DYNAMIC_SALT that would tell the rest of JtR that salt() returns a dynamically allocated salt of arbitrary size and encodes the actual size in first size_t of the returned buffer. It's almost the same as above, except that it has less pointer indirection. Since we intend to use this for cases where salts are large, I think the dynamic allocation should be made in a way that can be free()d, and the rest of JtR should actually be free()ing these as appropriate. 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.