Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 16 Nov 2005 13:12:14 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Speed up John

On Wed, Nov 16, 2005 at 10:57:52AM +0100, Simon Marechal wrote:
> Michael Behrisch wrote:
> > No, my idea was to use john --stdout on the client side. The setup would be 
> > as follows. The client connects to the server and says "ready to crack".
> > The server says OK, please take password 1000 to 2000, the client runs
> > john --stdout, throws away the first 1000 and feeds the next 1000 into
> > john --stdin and then responds OK to the server which gives the next 
> > share and so forth. The server needs to know nothing about john, it just gives
> > the numbers which is very low bandwidth. This would also scale easily.
> 
> It would be O(number_of_keys_tried). When you want to crack password 10M
> to 11M, you'll have to generate 10M canditate passwords.
> 
> A workaround would be not to stop john -stdout at the end of cracking.

This workaround is actually a good idea, however the setup would still
not scale well since every node would have to generate and skip over
candidate passwords tried by all other nodes, crash recovery would be
very inefficient, and it would be almost impossible to handle failures
of individual nodes (how to re-assign a chunk if all nodes are already
past those candidate passwords?)

Much better algorithms do exist and I had one implemented back in 1997,
but I never made it into something I could release.

-- 
Alexander Peslyak <solar at openwall.com>
GPG key ID: B35D3598  fp: 6429 0D7E F130 C13E C929  6447 73C3 A290 B35D 3598
http://www.openwall.com - bringing security into open computing environments

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ