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.