[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 06 Jul 2014 00:51:11 +0200
From: magnum <john.magnum@...hmail.com>
To: john-users@...ts.openwall.com
Subject: Re: Salt dupe removal logic and format changes (Comments
wanted)
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, jfoug@....net 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).
Aye.
magnum
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.
