Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 29 Mar 2012 06:01:29 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Research ideas.

On Wed, Mar 28, 2012 at 05:07:51AM +0200, Lukas Odzioba wrote:
> 2012/3/24 Solar Designer <solar@...nwall.com>:
> > OK, please feel free to apply for that under GSoC - or would you rather
> > work on it outside of GSoC?
> I decided to apply GSOC, however I will have less time than last
> summer, and I am ok if others will be able to do more.

What do you mean by that?  You implement fewer new hash types and others
implement more?  And your focus is optimizations to already
GPU-supported hash types, right?  Should we give others preference when
deciding on who to accept, considering your reduced availability
compared to last year? ;-)

> > As it relates to performance optimizations, what criteria do we use to
> > determine success/failure?
> I think hashcat speed - 10% is good one, but really hard to achieve.

Sure.  So is this your target for this year's GSoC?

> We must decide what is more important, having limited formats but
> fast, or a lot of formats but much slower than other tools.

A mix of both.  In order for JtR's GPU support to be "for real", we need
to have at least a few of the hash types achieve speeds similar to (or
better) than what other tools achieve.  It is great that we're already
there for phpass/CUDA (thank you!), but we need more.

It also makes sense to support hash types (on GPU) that others don't, as
long as there's at least some significant speedup over CPU.

As to having slow GPU code for hashes that others support as well (and
do so much better), this is of more limited benefit (mostly useful for
further development).

> My problem with optimization is that I cannot predict how much time I
> will spend on making something x percent faster. Sometimes you just
> got an idea, code it in 15 minutes and get 30% boost sometimes after
> whole night of tweaking you've got 2-3%.

Of course.

> Thanks all for ideas, myrice is coding DES, so I will try WPA-PSK.

Please do try WPA-PSK.  myrice is not coding DES currently, so you may
work on that as well.

Thanks,

Alexander

Powered by blists - more mailing lists

Your e-mail address:

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