Date: Tue, 13 Aug 2013 09:29:31 +0400 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: key-length for mask mode. Sayantan, On Tue, Aug 13, 2013 at 10:40:41AM +0530, Sayantan Datta wrote: > 0g 0:00:00:08 0g/s 3762Kp/s 2794Mc/s 36066GC/s aacujquq..aacxvglr BTW, this reporting indicates a problem: we're probably not updating the candidate password count to account for increase of *pcount (which happens due to on-GPU mask mode). With a saltless hash like raw MD5, we should see the same p/s and c/s rate (but higher C/s rate when there are multiple loaded hashes). Here we're seeing a p/s rate that is almost 1000 times lower than the c/s rate, presumably because it does not account for the mask. This issue is in the core tree, although obviously it is only exposed when a format actually starts updating *pcount (which is not yet the case for any format in the core tree itself). We'll need to think of how/where to fix it best. Perhaps it'd be in one of the functions in cracker.c. A difficulty: it is not obvious what to do when one of the crypt_all() calls sets *pcount to a different value than another call for the same set of original candidate passwords (but for a different salts). Maybe this should never happen. Maybe when it does happen, we should use max... or min? 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.