[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120413212619.GB15527@debian>
Date: Sat, 14 Apr 2012 01:26:19 +0400
From: Aleksey Cherepanov <aleksey.4erepanov@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: automation equipped working place of hash cracker,
proposal
On Fri, Apr 13, 2012 at 04:14:49PM -0400, Rich Rumble wrote:
> On Fri, Apr 13, 2012 at 3:27 PM, Frank Dittrich
> <frank_dittrich@...mail.com> wrote:
> > It is less predictable what hardware will be available at which time.
> >
> > You have much less influence on what people do during the contest than
> > you have in a team of pen testers... (After all, many people will just
> > take part in the challenge because they think it is fun, and they'll
> > avoid doing things which they don't see as "having fun", even if this
> > might result in trying out things that are less than optimal.
> >
> > Many people will be behind a firewall or router which prevents access
> > from outside (e.g., a central server), others might not want to grant
> > other people or a central server access to their systems, so you might
> > have to find ways to allow people fetching the next tasks to be
> > processed and sending back the results on their own.
> Last year I proposed a "Live CD/DVD/USB" that contained generic JtR
> binaries or that could compile JtR on the hardware if that might be
> beneficial, perhaps the CPU on one machine has AES in hardware, or has
> 3 Nvidia cards etc...
I thought about autobuilding tool to take the most from remote computers
during distribution independently of hardware. For instance script on end
machine tries to build different johns with different settings to measure
speed and choose best configuration (or best configurations specific for
different tasks).
Though I do not know either it is important or not: we would have other places
with overheads (especially if we consider to recheck candidates given to
untrusted machines), on the other hand just easy deployment could bring a lot
of machines to not care about overheads so much because from some point amount
of hardware could grow 10 times to provide just 10% improvement of cracking
(in other words does not really matter).
> That may be overboard, I just like to think fantasical like that,
> number one because I can and B because I have no programming skill to
> speak of, so when I see these awesome things being done on this list,
> I think, yeah THEY could totally do that :p
Thanks!
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.
