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.