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

On Thu, Jul 05, 2012 at 11:24:59AM +0800, myrice wrote:
> In my xsha512-cuda, I set MIN_KEYS_PER_CRYPT=MAX_KEYS_PER_CRYPT =
> 128*1024. So it allocates 128*1024 keys and hashes.
[...]
>     However, when I do ./john -te=xsha512-cuda
> ../jtrTestSuite/XSHA512_tst.in . The john uses up to 4.4GB memory on
> bull.
[...]
> Besides, in self test or if I gave a wordlist to john, mean I do
> ./john -te=xsha512-cuda ../jtrTestSuite/XSHA512_tst.in
> -wo=../jtrTestSuite/pw.dic, it will not take so much memory.
> 
> I just curious about it. Does single or incremental mode uses so much memory?

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?

BTW, if you load more hashes (or rather, more different salts), memory
usage will grow even further, because single crack mode allocates full
candidate password buffers (for min_keys_per_crypt passwords) per salt.

Alexander

Powered by blists - more mailing lists

Your e-mail address:

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