|
Message-ID: <25cc79f1e3c9b39aa279732432f36a6d@smtp.hushmail.com> 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.