Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 6 Jul 2014 11:35:28 +0400
From: Solar Designer <>
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.


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.