[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 3 Feb 2013 03:44:03 +0100
From: magnum <john.magnum@...hmail.com>
To: "john-dev@...ts.openwall.com" <john-dev@...ts.openwall.com>
Subject: Re: Speeding up WPAPSK, by leveraging salt shortcomings
On 3 Feb, 2013, at 3:26 , <jfoug@....net> wrote:
> ---- 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,
We do know this from to the spec. in formats.h. The pointer will be NULL for self-test and benchmarks, so we must check that.
> 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).
But if we get many non-hash formats that can benefit from this (I'm pretty sure we already have some more) it is more reasonable to use shared code and the new method. Maybe we should take a look at some more of the non hashes. Especially ones that do PBKDF2 or are otherwise very slow.
Please do not cc me for list messages. For some odd reason it makes my MUA address my replies to you only.
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.
