[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <316a57aefa6594805986fc0b60e0845a@smtp.hushmail.com>
Date: Wed, 30 Jan 2013 04:00:03 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Speeding up WPAPSK, by leveraging salt shortcomings
We could implement this right now, while we think about a full solution. It won't hurt performance at all, but it will do wonders for input files that only contain one essid (but possibly lots of authentications) and for files that ended up with some consecutive same-essids just out of luck, or by manual sorting.
magnum
On 30 Jan, 2013, at 1:10 , jfoug <jfoug@....net> wrote:
> That may very well be something to look at!
>
> new_keys is trivial. just a flag set to 1 in clear_keys(), and set to 0 at
> the bottom of crypt_all. Then simply memcpy the ssid at the end of
> crypt_all.
>
> but like you mention, that prereq is a bear. It would almost require some
> way of hooking some function from the format, INTO the hash loader, so that
> the salts were built in a required sorted order. I would think doing such
> with the store order of the input file would be a bad way to proceed.
>
> I will have to think more about this. This is a truely simplistic way. It
> still treats things as 200 'unique' salts (from my prior email), but the
> crypt_all would be smart enough, to only perform 91 PBKDF2 blocks, and skip
> 109 of them. The speedup in the end is the same.
>
>
>
> From: magnum [mailto:john.magnum@...hmail.com]
>
> On 29 Jan, 2013, at 17:55 , jfoug <jfoug@....net> wrote:
>> So, in reality, we do have 10 unique salts. However, during our call
>> to crypt_all, we should only perform the 2 block PBKDF2(4096) one time.
> However, the way JtR 'works', is it calls while (more_salts) {
>> set_salt(cur_salt++);
>> crypt_all()
>> cmp_all()
>> }
>
> Here's a beautyfully simple thought: If we could force John to serve the
> salts (the current code's salt structs) in essid order, so any same-essid
> salts would always be *consecutive*, we'd do fine with this one-line change
> to crypt_all:
>
> crypt_all(count)
> {
> + if (new_keys || strcmp(last_essid, cur_salt->essid))
> for (i = just like current code)
> pbkdf2(just like current code)
>
> post_process(count);
> }
>
> Unless I'm confused now, this is all there is to it (except trivially
> introducing new_keys and last_essid). But how would we accomplish that
> prerequisite? We could have pcap2john sort its output, but would that
> guarantee John would use them in that order? Anyway this would be non-ideal
> - eg. if concatenating input files, they might become unsorted.
>
> 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.
