Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 23 Jan 2009 10:14:45 +0300
From: Solar Designer <>
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 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:

> 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.


> 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.


> 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.


To unsubscribe, e-mail 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.