[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <18652bce219ce8f953fcd404d2974616@smtp.hushmail.com>
Date: Mon, 10 Jun 2013 09:21:05 +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 8:35 , Sayantan Datta <std2048@...il.com> wrote:
> 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.
I though there was a dummy call already in place somewhere... but it makes sense there is none until we implement mask mode.
> 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.
In the format params? Is it not better to leave them as-is and state that max_keys_per_crypt is given *without* accounting for set_mask, as already is the case. But cracker.c should account for the set-mask "multiplier" in crk_password_loop() like this:
1. format auto-tune says it thinks 40960 keys per crypt is sweet (just like today).
2. mask mode says it will generate 256 variations of each key.
3. self-test tests 40960 keys per crypt (just like today).
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.
magnum
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.
