Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 1 Feb 2013 10:18:00 +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 10:06 , magnum <john.magnum@...hmail.com> wrote:
> On 1 Feb, 2013, at 2:33 , <jfoug@....net> wrote:
>> 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.

We have a third option of course: Apply the patch as-is, with "if wpapsk" in loader.c. I do not mind that at all for now. In fact we should definitely add it as-is to unstable/Jumbo-8 regardless of what we do to bleeding. So please post the patch!

magnum

Powered by blists - more mailing lists

Your e-mail address:

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