[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 30 Jan 2013 00:47:02 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Speeding up WPAPSK, by leveraging salt shortcomings
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.
