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 [ CONTENT OF TYPE application/octet-stream SKIPPED ] -- 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
Powered by Openwall GNU/*/Linux - Powered by OpenVZ