[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 29 Jan 2013 21:14:57 -0600
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: Speeding up WPAPSK, by leveraging salt shortcomings
I am going to quickly do this on CPU, just as a test. I may also look at
adding this format to pass_gen, so that we can get data easier than using
airodunp and aireplay
-----Original Message-----
From: magnum [mailto:john.magnum@...hmail.com]
Sent: Tuesday, January 29, 2013 21:00
To: john-dev@...ts.openwall.com
Subject: Re: [john-dev] 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.
