[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2a8dd4f10b746d65a25acf441761e548@smtp.hushmail.com>
Date: Tue, 3 Sep 2013 15:18:45 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: crk_timestamps
On 3 Sep, 2013, at 14:43 , Solar Designer <solar@...nwall.com> wrote:
>> Our first fix seemed simple enough until Sayantan saw it trying to allocate 22 GB of memory :-) but I'm not yet sure the second fix really does it.
>
> Rather than allocate potentially huge amounts of memory, I think we
> should accept potentially writing some duplicate lines to the pot file,
> which is harmless. We could avoid both issues by switching to a
> different approach, but I think it's not worth it.
>
> So instead of the ridiculous num_internal_keys stuff, we should simply
> not record timestamps that are above the allocated size - and we should
> keep the allocated size to be based on max_keys_per_crypt alone (after
> format init, though). This means that with GPU-mask-enabled formats,
> this dupe elimination will be mostly non-working, whereas with other
> formats (as well as when not using mask mode) it will work like it did.
So basically we revert to the original allocation of crk_timestamps, and then we skip the dupe check in crk_process_key() [setting dupe=0] whenever index > max_keys_per_crypt and that's it, right?
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.
