[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 10 Jun 2013 18:11:32 +0530
From: Sayantan Datta <std2048@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: peculiar problem with fmt->params.max_keys_per_crypt
in bleeding
Hi ,
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.
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).
> 4. crk_init() allocates space for 40960 timestamps (just like today).
> 5. wordlist, or whatever cracking mode is used, generates keys.
> 6. cracker.c collects 160 (==40960/256) such keys and then calls
> crypt_all().
> 7. GPU mask mode produces 40960 keys from the 160 it got.
>
I agree with the rest.
Regards,
Sayantan
Content of type "text/html" skipped
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.
