Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 06 Jul 2014 00:51:11 +0200
From: magnum <>
Subject: Re: Salt dupe removal logic and format changes (Comments

Not sure why this was moved here from john-dev but anyways,

On 2014-07-05 15:40, Solar Designer wrote:
> On Sat, Jul 05, 2014 at 08:46:51AM -0400, wrote:
>> Magnum and I have talked a little at attacking this problem with a format change.    To give a 2nd salt size into the format structure.
> 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.

>> It may be that we need a new method to be added to the format equal_salt() or something like that, vs this size.
> This is also a good approach, a more object oriented one I'd say.
> Maybe call the new method saltcmp()?  (If you choose this approach.)
> FMT_SALT_STRUCT is more of a hack, but it avoids needing to change
> existing formats.  saltcmp() is cleaner and more generic, but it
> involves changes to all format structs (unless you add it to the very
> end and treat NULL as requesting the current behavior, but that's a
> hack, so FMT_SALT_STRUCT feels cleaner then).



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.