Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.