[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <070201cdfe7e$2fce5c40$8f6b14c0$@net>
Date: Tue, 29 Jan 2013 18:10:18 -0600
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: Speeding up WPAPSK, by leveraging salt shortcomings
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.
