[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140705134022.GA4940@openwall.com>
Date: Sat, 5 Jul 2014 17:40:23 +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 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.
> 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).
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.
