[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130607141210.GA24758@openwall.com>
Date: Fri, 7 Jun 2013 18:12:10 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: peculiar problem with fmt->params.max_keys_per_crypt in bleeding
Sayantan -
On Fri, Jun 07, 2013 at 06:15:20PM +0530, Sayantan Datta wrote:
> I am getting random segmentation faults when crypt all returns anything
> greater than fmt->params.max_keys_per_crypt.
Didn't this work for you before, in your descrypt-opencl with hard-coded
all-numeric passwords pattern experiment?
> The problem goes away if I
> simply increase max_keys_per_crypt which I don't want to. Is this even a
> problem or is it by design ?
It's not by design. There must be a bug, perhaps in your format not
supporting other format methods on index values beyond max_keys_per_crypt.
If your crypt_all() returns such values, then many of your other methods
must be prepared to be called with such values.
As the comment on crypt_all() in formats.h says:
* [irrelevant portion] The indices passed to get_key(), get_hash[](),
* cmp_one(), and cmp_exact() must be in the 0 to crypt_all() return value
* minus 1 range, although for infrequent status reporting get_key() may also
* be called on indices previously supplied to set_key() as well as on indices
* up to the updated *count minus 1 even if they're beyond this range.
* The count passed to cmp_all() must be equal to crypt_all()'s return value.
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.
