Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ