Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ