Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 10 Jun 2013 20:35:11 +0200
From: "magnum" <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: peculiar problem with fmt->params.max_keys_per_crypt in bleeding

On 10 Jun, 2013, at 14:41 , Sayantan Datta <std2048@...il.com> wrote:
> On Mon, Jun 10, 2013 at 12:51 PM, magnum <john.magnum@...hmail.com> wrote:
> 1. format auto-tune says it thinks 40960 keys per crypt is sweet (just like today).
> 
> I don't want to initializing john's data bases for 40960 keys.For des optimal number of keys is around 419430 and it consumes around ~1min just to initialize the john's databases which does not include any opencl initialization time. I keep keys count for descrypt way below optimal to avoid this problem. If we double the number of keys ,it takes forever to initialize the databases.  So it would be better if we could just initialize the databases for 160 keys and not 40960 keys.

Either your MUA is broken, or mine is - one can't tell the quotes from your replies. Anyway, 40960 was obviously just an example and my point is that autotuning will come up with a figure suitable for keys *with* masks. You can of course override autotuning, using GWS environment variable or other means. We might want to eventually autotune using mask mode but that is for later.

> 2. mask mode says it will generate 256 variations of each key.
> 3. self-test tests 40960 keys per crypt (just like today).
> 
> Self test tests 160 keys but computes 40960 hashes(for benchmark we can update *pcount parameter and return the original *pcount value).

Eventually, the self-tests will need to use mask mode but they currently don't. If you like to spend time on this early on, fine with me. It might be trivial once you have the format's stuff in place.

magnum

Powered by blists - more mailing lists

Your e-mail address:

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