Date: Fri, 23 Jan 2009 10:14:45 +0300 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: keyspace, mask password and dumb bruteforce On Wed, Jan 21, 2009 at 09:51:47PM -0600, Billy Newsom wrote: > Yeah, you bet that the distributed.net and SETI type of projects are > neither efficient or intuitive if you are going to compare it against the > socially-engineered thinking behind John. Not my point at all. I was > originally saying that if you take a project with all its networking bells > and distribution whistles, and you make the server run smart like John to > socially engineer a fast password crack, and send out the best candidate > choices to the client johns, then you will get the best of #1 intelligent > cracking and speed, and #2, distribution and key management (or should I > say candidate management). Well, you did not make this point before. You made it now. I agree. > Whatever the goal is, whether its dumb brute forcing RC5-72 or it is > intelligently cracking NTLM passwords, you can use a hive mentality to make > sure everything buzzes along from one central command head. Again, my point > is that the distributed projects have the networking and sharing loads > code, which is pretty well established. The concept is similar, yet different. The code that they have is of no use here. > John is a fast cracker. Just do > both. The master john would be the queen and decide who in the hive gets > what. I'm all for it. If I didn't have many things competing for my time, I would have already implemented it (as well as many other things). My suggested approach for doing it for "incremental mode" is briefly described in this posting I referred to the other day: http://www.openwall.com/lists/john-users/2005/11/21/2 > The idea is to split up the process WAY SMARTER than telling core 0 > to try 0-5 character passwords, core 1 to try 6 characters, core 2 to try 7 > characters, and core 4 gets the nice and not-so-equal job of trying 8 > characters. Indeed. > That is the sort of advice we read about john when someone > talks about distributing load. It's absurd. It's not exactly absurd. It's decent advice by someone who hasn't implemented anything better in a way suitable for an end-user, given to an end-user. > And to get on with it, the exact same principle of the queen bee > distributor of the candidates can apply equally well with a multi-core PC > of 2016, which might have 64 cores, and a distributed network of 100 > rackmounted servers, available today. Correct. > And one more thing. This may sound like a wild idea, but probably in the > next few years, we won't have to run john or jack or jill or any cracker > for some of the older types of password tables. We will likely just find > someone's rainbow tables with, for example all of the md5 hashes with or > without salt, SHA1 or whatever, and perhaps we pay them a nominal fee, but > we just type in the hash and salt, and they will have the data in a MySQL > database that they have generated. Free versions of many millions of hashes > are already available today. So basically, it will be faster for them to > give you the answer than it does to take your PayPal money. For many saltless hashes, this is already the reality, but it won't ever(*) be for salted ones, as long as the "salt space" is large enough and no single salt value is substantially more common than average. The old traditional DES-based crypt(3) with its 12-bit salts is an exception - 12 bits is not "large enough" - but it's also nearly the only widespread exception. Most other salted hashes use larger salts. (*) This is a bold statement, but I left "large enough" without a precise definition, so it's a true statement. In practice, I think uniformly distributed cryptographically random 48-bit salts are good enough to thwart precomputation attacks in the foreseeable future. > I mean with all of the time spent on cracking, not too much effort has been > put into just doing a hash ONCE and for all, and then just comparing its > result on the fly the next time you need it. Why, there are plenty of rainbow tables out there. Alexander -- To unsubscribe, e-mail john-users-unsubscribe@...ts.openwall.com and reply to the automated confirmation request that will be sent to you.
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.