Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120515200701.GA21792@debian>
Date: Wed, 16 May 2012 00:07:01 +0400
From: Aleksey Cherepanov <aleksey.4erepanov@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: using all available hardware

On Tue, May 15, 2012 at 09:07:20AM +0200, Frank Dittrich wrote:
> On 05/15/2012 07:01 AM, Simon Marechal wrote:
> > I am not sure this overhead should be put on the server side. A place to
> > rsync could me transmitted to clients and they should start downloading
> > in the background. Then there might be a way to encode this information
> > in a stateless manner. For example a client could advertise his
> > capabilities everytime it asks for work.
> 
> You are probably right. To be on the safe side, we should avoid putting
> unnecessary work on the server, so that the server can handle a larger
> number of clients.
> 
> >> The wrapper could also prevent the client from requesting too many tasks
> >> in advance. (IMHO, it is OK to download some more tasks than available
> >> CPU cores, so that a client can immediately start the next attack when
> >> one attack is finished.)
> > I did not follow all the discussion, but why is it a good idea to ask
> > for tasks in advance ?
> 
> May be it isn't. I thought it would be necessary to avoid delays when
> the client needs to download a huge wordlist file before starting a task.
> But if you distribute those files prior to the pen test / contest, or if
> the clients can download them while still working on a cracking task
> (and prior to fetching the next task), then this might not be needed.

It seems that we need separate action: prepare for attack. So user can
download all stuff without starting attack.

Also there could be a script that computes (or ask the server for)
optimal behaviour and then show. And for automated mode there should
be a daemon that knows about attacks in run on that machine and could
run command according to information about optimal behaviour.

By the way I realized that enough information about progress could be
captured using --status. So I do not need a full wrapper. That makes
things easier (or it seems to me to be so).

Regards,
Aleksey Cherepanov

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.