[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c94f648dbbb6dc2c85f41a9d41318fb5@smtp.hushmail.com>
Date: Wed, 30 Jan 2013 04:20:09 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Speeding up WPAPSK, by leveraging salt shortcomings
BTW, the *cap2john utility should put the essid in a login field. This way, with just this one-line patch, you can take advantage of the same-essid optimization by just attacking one essid at a time, using
./john wpapsk.in -user:netgear
Another really great advantage is that Single mode will permute essids into candidates. That might prove very rewarding.
Also, the utility should definitely fill in the bssid (mac address) in some field. How else would you know *which* of the 110 "netgear" you cracked? As we can't use colons, this must be in dash form (de-ad-ba-be-ca-fe) or compressed (deadbabecafe) and could be put in the uid field or whatever (but NOT a fields read by Single!).
magnum
On 30 Jan, 2013, at 4:00 , magnum <john.magnum@...hmail.com> wrote:
> 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.
