Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 13 Mar 2007 08:21:25 +0100
From: Pablo Fernandez <>
Subject: Re: Splitting the Charset into chunks


Thanks for your advice. I think I will finally go for the external:parallel 
option, mainly because of it's cleanness, and also for it's pretty good 
performance. See below:

> > I've tested how ineficient it is, and it came out to be quite ok. For
> > 1000 nodes there's a 25% loss on every node, for 250 there's an 8%. I've
> > tried with more numbers, and came out to this relation: 0.030% loss in
> > every node for each node, 0.025% above 1000 nodes, and 0.008% above 10000
> > nodes probably thanks to the cache :)
> >
> > Those seem to be good numbers, but they're not in a very big cluster. If
> > you've got 10000 machines you loose 80% of the power in every machine
> > looking for the next word to try. So, I think I'll try to write code for
> > a small cluster (let's say 300 nodes with 10% loss... after all, having
> > access to 10k machines is not that easy xD, but still 10% is big) unless
> > anybody knows a better way to split the charset.
> The above numbers don't mean anything without you also mentioning the
> hash type and number of different salts.

Ok, I understood your point. Now I've got some more -better- numbers:
I made 2 series of each test to average results. The machine I used is an 
isolated, fresh basic install one. Each test is a batch with the same passwd 
file, taking different node numbers. There is a test with 20 MD5 -slow- salts 
and a test with 50 DES -fast- salts. For each test I tried:
. Without the external filter (0)
. With the external filter set to 1/1
. With the external filter set to 1/25, 1/50, 1/100, 1/200, ..., 1/12800

I have prepaired an spreadsheet (I attach it for the public interest) but 
basically it says that, with slow hashes, the loss is minimal. It does not 
reach the 1% for each node until 300 nodes, touches 10% after 6000 nodes, 
with 20% at 128000.
But for the fast hash it is at 1% at 25 nodes, 10% at 400 nodes, 50% at 5000. 
Much worse.

Well, I suppose everything is how you look at it. You're looking for 
passwords, right? How many machines you've got access to? 10? 50? 100??? With 
100 nodes the loss for an slow hash is 0.69%, and for a fast hash is 2.94%, 
it's really nothing.

It might be worth in the future to hack the .chr file to scalate this to much 
higher nodecount. For example, let's say we can split the .chr file into 200 
pieces: we may then have 500.000 nodes with an slow hash, or 40.000 nodes 
with a fast hash, with just 5% loss in each node.

So, I'll begin coding an external app that runs john with the external filter 
on a GRID environment. And unless hacking the .chr file takes just a few 
hours (I *really* don't know how to do it, some help will be appreciated) I 
will leave it for the version 2.0


Download attachment "jtr_external_parallel_loss.sxc" of type "application/octet-stream" (6474 bytes)

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.