Date: Mon, 10 Jun 2013 12:05:06 +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 11:17 AM, magnum <john.magnum@...hmail.com> wrote: > This looks like a core bug to me, or I don't understand the intent. The > above is in crk_init() - I hope this is after fmt_init() where we (even in > OMP) normally tune max_keys_per_crypt. At what point is set_mask() called? > Maybe that function should decrease max_keys_per_crypt accordingly, so that > the total max_keys_per_crypt (which was reported at first and used for the > allocation in crkinit()) will hold the "running" max_keys_per_crypt that is > lower but will be amplified with the set_mask variations. However, I see > that format.params are *copied* to crk.params so if you change it after > crk_init(), cracker.c will still use the old value. So I can't see how all > this can fit together without slight core changes. We don't have the mask mode in bleeding yet. Also the crk_init() is called after reset(), so changing the max_kpc in reset doesn't work either. We can change the max_kpc in crypt_all() but it is definitely not the right place to do that (even though it works). Another problem is that when max_kpc is very high at the beginning it takes quite long for the format to initialize and results in unnecessary wastage of memory. My suggestion is that we include another parameter say expected_keys_count which will be used to for allocating the memory so that we can keep max_keys_per_crypt very low from the beginning. Regrards, 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.