Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 30 Jan 2013 14:02:21 -0600
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: Speeding up WPAPSK, by leveraging salt shortcomings

From: magnum [mailto:john.magnum@...hmail.com] 
>
>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:

Been thinking a little on this one. This is the first time (that I am aware
of), where order of salts makes a difference. so up to this point, I think
there has been no thought put into it. How about this:

1. make an array of pointers into the salt data (it may, or likely is done
this way already).

2. the salt loading currently does load_salts, strike_out_pot,
build_final_salt.  It is not exactly like this, but I think this explanation
is close enough so that solar (or magnum) would know the exact mechanics.

3. I propose we add an optional step to this loading.  It will be 'similar'
to a qsort.

This would require changing the format. There will be an 'optional' (almost
always set to default) method added.  This method will be like the function
used by qsort, and hell, we even COULD use qsort to actually do it.  qsort
is:   

qsort(void *_Base, size_t _NumElements, size_t _sizeOfElement, int(__cdecl
*_ptFuncCompare(const void *, const void*))

So, I propose we add a new function to format methods. This function is:

int salt_sort(const void*, const void*);

Then if this function is not set to default_salt_sort, we call qsort on our
data, using that function as the compare function.  That function would have
to be either given a pointer to the salt itself, or would have to be smart
enough to convert the pointers given into the proper structure, so that the
salt could be located.

However, is 'should' be the format, that is in charge of ordering salts. The
format designer will need to know that it DOES matter, and know exactly how
to order things.  That way common CRTL functions like qsort would properly
order this data, even if we had several formats needing this work.  JtR
would not need to know anything to do this, the format would own any logic
on what is needed.

On a side thought, would this same method be beneficial for sorting input
words??

Jim.

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.