Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 3 Sep 2013 15:18:45 +0200
From: magnum <>
Subject: Re: crk_timestamps

On 3 Sep, 2013, at 14:43 , Solar Designer <> 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?


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.