[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130903124346.GB20719@openwall.com>
Date: Tue, 3 Sep 2013 16:43:46 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: crk_timestamps
magnum -
On Mon, Sep 02, 2013 at 10:02:41PM +0200, magnum wrote:
> Regarding https://github.com/magnumripper/JohnTheRipper/issues/328 which I'm not at all sure we are done with:
>
> What is crk_timestamps for? Is it about having user1:hash as well as user2:hash (using same hash)? Or what kind of dupes are we catching?
Yes, duplicate hashes that somehow were not removed by the loader (as
you know, the loader may preserve those dupes in some special cases).
> 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.
Alexander
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.
