Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ