[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8651e8e4113231681b9f17fbb1dc6f8b@smtp.hushmail.com>
Date: Fri, 1 Feb 2013 10:06:50 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Speeding up WPAPSK, by leveraging salt shortcomings
On 1 Feb, 2013, at 2:33 , <jfoug@....net> wrote:
> Ok, I have been able to do this, VERY easily. I am doing this as a POC, before digging into bleeding (since it is a change to every format file out there).
>
> So, here was what I have done.
> ...
> 7. a function: int ldr_salt_cmp(const void*, const void*) was created in loader. This is the function passed into qsort.
> ...
> 9. at this POC time, the salt_compare is simply a tiny static function in loader. But this would be the same function as to be placed into wpapsk_fmt.c (or cuda or opencl).
This sounds all good to me. However,
> 10 this function simply does this: int salt_compare(const void *x, const void *y) { return strcmp((const char*)x, (const char*)y); } i.e. pretty trivial for this example, but it is all that is needed, since the essid item is the first thing in our wpapsk structure.
Being simplistic again (and trying to avoid format struct changes), how about this idea: We don't let the formats provide this function. Instead we *always* use that exact static function in loader.c (with strncmp though). So if a format needs this, it provides the needed data first thing in the salt (struct). If not, well we would sort salts for formats that does not need it - but this doesn't matter, does it? Perhaps we should cap it as strncmp(x, y, MIN(fmt->params.salt_size, 64)) or some other max. figure (adding a SALT_SORT_MAX in params.h).
> But all in all, this was a pretty easy change. I just had to step code for a while, looking for where to put it, and then dump some structures, looking for how it was all put together. I'm not quite sure where to go with this code right now. It needs a little cleaning, but might not be bad for J8. It would only execute right now, for wpapsk formats, that have more than 1 salt, so 'should' be safe. But I will wait for instructions from others.
I see no problems with adding this new format method except I don't want to divert from core (or next core) if I can avoid it at all. If Solar agrees to add it for 1.8, I'd like to add it to bleeding right now.
Otherwise perhaps we could try my idea... Will it slow loading of 10,000 crypt-md5 salts? Probably not much. Would it hurt any format? Not likely. It will be less flexible for future formats though.
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.
