[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20130203031533.BHZ1W.129938.imail@eastrmwml108>
Date: Sat, 2 Feb 2013 22:15:33 -0500
From: <jfoug@....net>
To: john-dev@...ts.openwall.com
Subject: Re: Speeding up WPAPSK, by leveraging salt shortcomings
---- magnum <john.magnum@...hmail.com> wrote:
> But if we get many non-hash formats that can benefit from this (I'm pretty sure we already have some more) it is more reasonable to use shared code and the new method. Maybe we should take a look at some more of the non hashes. Especially ones that do PBKDF2 or are otherwise very slow.
Not only do we need something that is time consuming and dependent on only part of the salt, but also that part (which the heavy CPU part depends upon), really needs to be something likely non-random (like user names, the SSID in wpapsk, etc). If the user has control over this part of the salt, all the better.
But it MAY also have a benefit, if the same site/user ends up in our input file, with multiple salts. This can often be seen with wpapsk, where you can sniff the same AP multiple times. Each time you do that, you get a different salt. Thus, over time (or if multiple people combined input files), you would have many of the same SSID. We can now handle this, without 'too' much overhead. There is some overhead, but no where near as bad as before. Just because of this type 'fact', there may be numerous other formats, which we could add this 'trick' to (part salt processing). I have not looked into enough of the other non-hash formats to really know. But could it even be the case for some of the NET* types??? Could you end up with multiple hashes, with multiple salts, that are all for the same user/site ?
H.
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.
