[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120430110918.GB8024@openwall.com>
Date: Mon, 30 Apr 2012 15:09:18 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Password Generation on GPU
On Mon, Apr 30, 2012 at 11:30:10AM +0200, Frank Dittrich wrote:
> Of course, it should be possible to use a subset of the most likely
> final characters first, and use less likely final characters as a mask
> in a separate session.
> (The optimal minimum size of the mask probably depends on how much of a
> bottleneck the memory bandwidth is.)
>
> When we generate chr files for (maxlen-1) anyway, it would also be
> possible to compute an "optimal" mask of final characters, and may be
> even include this into the chr file, to be used as the default mask.
>
> (Of course, the new chr files will then not just be suboptimal for
> regular usage without masking, but even incompatible.)
The above corresponds to another approach to the problem that I haven't
mentioned yet, but I will now:
We can allow for stacking of the --mask mode on top of other cracking
modes, much like --external filter()s are currently stackable on top of
other cracking modes. This will let us avoid having to enhance the
incremental and wordlist modes in any other way (except for allowing for
such stacking), yet let them benefit from on-GPU candidate password
generation inner loop (for the mask portion). Other crackers call the
wordlist + mask variation of this a "hybrid" mode.
We may in fact do that.
Anyhow, the first steps are to implement the set_mask() formats
interface enhancement and the mask mode. Then we'll have several ways
to make this functionality available along with other cracking modes.
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.
