Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 9 Jul 2012 06:14:46 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: About very high memory usage

myrice -

On Thu, Jul 05, 2012 at 03:56:16PM +0800, myrice wrote:
> On Thu, Jul 5, 2012 at 1:17 PM, Solar Designer <solar@...nwall.com> wrote:
> > Single crack mode does when you set min_keys_per_crypt this high, which
> > was not expected when I designed this mode in almost its current form in
> > 1998.  We have two settings - min_keys_per_crypt and max_keys_per_crypt -
> > precisely to make single crack mode behave better.  The "min" should
> > in fact be as low as possible while achieving reasonable performance.
> > It is OK if the performance achieved at that setting is, say, twice
> > worse than at "max".  What would your "min" need to be for that?  And if
> > we allow for 10x worse c/s rate?
> 
> I got it. I set my "min" to be this since I want to full use GPU
> resource(correspond to BLOCK_NUM*THREAD_NUM). I test  lower
> size(32*32), it takes 200MB+ memory. The memory seems reasonable if we
> allocate every password candidate per salt. But it is a lot slower,
> only 42K c/s :(

42K c/s?  Is that like a thousand times slower than normal, and a lot
slower than a CPU as well?  If so, that's not really usable.  Maybe you
have some loops that go until your max_keys_per_crypt regardless of the
actual number of keys?  If so, can you adjust those to go until the
actual number without incurring much performance impact on supporting
this variable count?

Also, 200 MB for just a thousand of hashes (and salts) is still a lot,
considering that it is reasonable to run John on millions of hashes at
once (this is often being done).

Maybe we need to declare single crack mode as unusable with many GPU
formats, but supporting lower/variable keys_per_crypt is desirable
anyway (e.g., if running with a small wordlist).

Thanks,

Alexander

Powered by blists - more mailing lists

Your e-mail address:

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