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.