Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 21 Jan 2009 17:37:52 +0300
From: Solar Designer <>
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:

(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:


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.