[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+TsHUCpdvFENKVnXA4sKTaNHN6aUChpwOhNVkiOJAC6K_bNaw@mail.gmail.com>
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.
