[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
