[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <07a901ce007e$a31429d0$e93c7d70$@net>
Date: Fri, 1 Feb 2013 07:18:33 -0600
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: Speeding up WPAPSK, by leveraging salt shortcomings
Here is the patch. I have kept my debugging code in it (for now). The
debugging is mostly the extra data in the structure, and using an array, vs
a memory allocated array. But the debug code is wrapped with a #define, so
unless that is defined, the extra crap will not be there.
The very first function in the patch file (the salt_compare) would be the
function to be placed into the format structure. That function could do
whatever it wanted, to a pair of CONST salt values, to determine which one
sorts before the other (or if they are the same in sorting value). The
actual function pointer passed into qsort is the next function, and it will
stay in loader.c That function understands the structure used to build the
array of link list salt items, and knows how to handle a db_salt structure
(to find the salt value). This causes 2 layers of indirection per qsort
compare call, but it is very little extra overhead. It is some pointer
math, and the cost of calling another function. It should not even be
noticeable.
The ldr_salt_sort is a static function, and simply checks to see if this
format should be sorted (right now, does the strncmp of "wpapsk"). Also, it
will quick bail out if there is less than 2 salts. I believe this 1 salt
check will cause any unsalted to bail out quickly.
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.
Jim.
-----Original Message-----
From: magnum [mailto:john.magnum@...hmail.com]
Sent: Friday, February 01, 2013 3:18
To: john-dev@...ts.openwall.com
Subject: Re: [john-dev] Speeding up WPAPSK, by leveraging salt shortcomings
On 1 Feb, 2013, at 10:06 , magnum <john.magnum@...hmail.com> wrote:
> On 1 Feb, 2013, at 2:33 , <jfoug@....net> wrote:
>> But all in all, this was a pretty easy change. I just had to step code
for a while, looking for where to put it, and then dump some structures,
looking for how it was all put together. I'm not quite sure where to go
with this code right now. It needs a little cleaning, but might not be bad
for J8. It would only execute right now, for wpapsk formats, that have more
than 1 salt, so 'should' be safe. But I will wait for instructions from
others.
>
> I see no problems with adding this new format method except I don't want
to divert from core (or next core) if I can avoid it at all. If Solar agrees
to add it for 1.8, I'd like to add it to bleeding right now.
>
> Otherwise perhaps we could try my idea... Will it slow loading of 10,000
crypt-md5 salts? Probably not much. Would it hurt any format? Not likely. It
will be less flexible for future formats though.
We have a third option of course: Apply the patch as-is, with "if wpapsk" in
loader.c. I do not mind that at all for now. In fact we should definitely
add it as-is to unstable/Jumbo-8 regardless of what we do to bleeding. So
please post the patch!
magnum
Download attachment "sort_salt.patch" of type "application/octet-stream" (6726 bytes)
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.
