[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200703130821.25807.pfernandez@13t.org>
Date: Tue, 13 Mar 2007 08:21:25 +0100
From: Pablo Fernandez <pfernandez@....org>
To: john-users@...ts.openwall.com
Subject: Re: Splitting the Charset into chunks
Hi,
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
Regards,
Pablo
Download attachment "jtr_external_parallel_loss.sxc" of type "application/octet-stream" (6474 bytes)
--
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.
