[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20140705141349.735QR.931176.imail@fed1rmwml205>
Date: Sat, 5 Jul 2014 14:13:49 -0400
From: <jfoug@....net>
To: john-users@...ts.openwall.com
Subject: Re: Salt dupe removal logic and format changes
(Comments wanted)
---- Solar Designer <solar@...nwall.com> 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.
>
> 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.)
This is one reason I thought it was a pretty good idea when I first had it. Now with name you have chosen, it 'may' be that we could even re-work the salt sorting logic, using this function, hmmm.
I would think saltcmp would only be able to be called after the format was fully init() done (I doubt get_salt can be called prior to that anyway).
I can see the method looking like:
int saltcmp(void *s1, void *s2, int salt_size, int orderonly);
That way it could be called like: saltcmp(s1, s2, 250, 0); and it would trigger the function to do a full comparison with the return being 0 or !0 for equality.
If called saltcmp(s1, s2, 250, 1), then it would simply return -1 if s1 orders less than s2, 0 if they order equal and 1 if s1 orders after s2. This could be used in the salt_sorting, instead of the hackish way it is done today.
this is pretty much fmt_default function:
int fmt_default_saltcmp(void *s1, void *s2, int len, int type) {
if (type) return 0;
return memcmp(s1, s2, len);
}
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.
