Date: Sun, 3 Feb 2013 01:16:05 +0100 From: magnum <john.magnum@...hmail.com> To: john-dev@...ts.openwall.com Subject: Re: Speeding up WPAPSK, by leveraging salt shortcomings On 1 Feb, 2013, at 14:18 , jfoug <jfoug@....net> wrote: > This patch is against unstable. There should be no side effects except for > runs against wpapsk hashes. For later building into bleeding, we could add > the salt_sort method to the format structure. Then build a > fmt_default_salt_format and set all formats to use that. Then move the > salt_sort function from loader into wpapsk*_fmt.c The ldr_salt_cmp would > call the format's salt_sort. And the check within ldr_sort_salts would be > changed from the strncmp of wpapsk to a check to see if the format's > salt_sort method is pointing to fmt_default_salt_sort or not. > > But I have not done bleeding yet. the code as it stands should also work in > bleeding, without change. It will simply keep it's hard coding to wpapsk. It just hits me the salt_db is exposed to the format in bleeding, as an argument to crypt_all(). Does this change anything? Maybe not. But I suppose we *could* sort that db at the very first call to crypt_all() after the reset() that signals that we are no longer in self-test. It would not be better, just different. For a very fast format, it would be suboptimal because it would be a conditional that is false for the rest of the session. No, wait. It gets better: the reset() function is passed db_main! This means we could do the whole sorting thing in a format-local reset() without any support from core nor from the format struct. And no performance hit for fast formats. Just food for thought. The patch is definitely perfect for unstable as-is, but we have some alternatives to consider in bleeding, if we want to. 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.