john-users - Re: keyspace, mask password and dumb bruteforce

Openwall GNU/*/Linux 3.0 - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 21 Jan 2009 18:22:01 -0600
From: Steve Bergman <sbergman27@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: keyspace, mask password and dumb bruteforce

Solar Designer wrote:
> The exception is when you're willing to throw a lot of computing
> resources at cracking one publicly known hash, and you cannot or don't
> care to optimize the order in which candidate passwords are tried.
>   
If I may throw in a comment to put this in a perspective that the mind 
can more easily grasp, (since the human mind tends not to deal well with 
extreme scale), the keyspace for a unix password of maximum length 8 is, 
I think, 95^8 + 95^7 + 95^6 + 95^5 + 95^4 + 95^3 + 95^2 + 95^1 + 95^0 = 
6704780954517121, which we can call about 6.7e15. This is a 
mind-bogglingly huge number. Last I looked, seti@...e, which is far and 
away *the* most popular distributed project (no other project on BOINC 
can touch it) had about a half a million cores running their client.  
Assuming that all of these cores are as fast as one core of a Q6600 
(which they aren't), and that  all of them ran full out 24 hours a day 
(which they don't), then if the *entire* power of the seti@...e 
distributed network were focused, with 0% efficiency loss due to 
distribution overhead, upon one md5 hash with one salt, without 
optimizing the password candidate order, they would be guaranteed to 
crack it in about 2 weeks.  On average it would take a week.

I'm no expert. But it seems to me that this is a problem where a little 
finesse is worth more than one *hell* of a lot of brute force.

Perhaps there is more potential in coming up with ideas to even further 
optimize candidate password selection for individual scenarios than 
there is in distributing the processing to more machines.  The 'brute' 
in 'brute force' is there for a reason. ;-)

-Steve

-- 
To unsubscribe, e-mail john-users-unsubscribe@...ts.openwall.com and reply
to the automated confirmation request that will be sent to you.