[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090121143752.GA7398@openwall.com>
Date: Wed, 21 Jan 2009 17:37:52 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: keyspace, mask password and dumb bruteforce
On Fri, Jan 16, 2009 at 03:49:28PM +0100, Samuele Giovanni Tonon wrote:
> A "collision free" algorithm is to simply scan through the keyspace by
> going incremental (i.e. 0000 0000, 0000 0001, 0000 0002 and so on...)
> and splitting our work in to "chunks" for each client.
> These chunks must be big enough to make the client work for some time
> (some hours/some minutes) and then give back a feedback to the server.
>
> Then there's Jtr and his incremental mode which, for what i've
> understand, will go to search the same keyspace as above but going to
> test some "most likely to be" passwords first; This way, unfortunately,
> is not higly distributed tough
Actually, it is not very hard to split the workload across multiple
nodes in a collision free way and without consuming much bandwidth while
still using JtR's incremental mode. Please see:
http://www.openwall.com/lists/john-users/2005/11/21/2
(especially the last paragraph).
> even the wiki has a list of jtr distributed attempt;
This doesn't mean much. People were implementing whatever they could
think of and whatever they wanted to.
> this way also means that those distributed attempts
> are most likely like this: there's a server which is producing the whole
> keyspace and sends it to the clients who will simply go as "wordlist
> cruncher". A con against this is that the server <-> client
> communication will be huge since each chunk (even if compressed) could
> take a lot to transfer over the network and at the end could compromise
> the whole purpose of being distributed.
While this is an obvious approach, and it is actually quite good for
extremely slow hashes and/or for large numbers of different salts loaded
for cracking at once, that's not how those JtR hacks work.
> As a quick solution to this problem i thought that maybe a solution is
> to use "mask passwords list", which is not an innovative idea but could
> work; with a mask password the user has the ability to restrict the
> keyspace and it is still easy to split up chunks across the clients.
> Basically it's making a bruteforce less dumb by using human brain other
> than using heuristics and each client can easily self-produce the
> keyspace to crunch, therefore saving network bandwith.
If I understood you correctly, you're essentially suggesting to split
the keyspace manually. Yes, this is what I recommend most of the time -
especially when the number of CPU cores to distribute the workload
across is relatively small. You might want to take a look at these
older postings:
http://www.openwall.com/lists/john-users/2008/04/08/4
http://www.openwall.com/lists/john-users/2005/08/24/4
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.
