Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 2 Feb 2013 21:26:06 -0500
From:  <jfoug@....net>
To: john-dev@...ts.openwall.com
Cc: magnum <john.magnum@...hmail.com>
Subject: Re: Speeding up WPAPSK, by leveraging salt shortcomings


---- magnum <john.magnum@...hmail.com> wrote: 
> 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 
>>  clip 
> 
> 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.

putting it into reset (if we KNOW that it is called just after self test, right before we get the 'real' data, and reset has access to the db_main (and thus, the db_salt *salts member, would make this 100% self contained within a format, impacting core not in the least.  However, if we had several formats needing this, then each would have to have knowledge of the inner workings of the db_main.  At this time, we have only ONE format needing this.  So we gain nothing by having core do it, vs having the format itself.  And we save ourselves from having to modify EVERY format, to simply list a default method within them.

I like that idea a lot (the reset() method).

Jim.

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ