[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130613003928.GA2698@openwall.com>
Date: Thu, 13 Jun 2013 04:39:28 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Mask mode for GPU
Hi Sayantan,
On Wed, Jun 12, 2013 at 09:19:11PM +0530, Sayantan Datta wrote:
> I read about the mask mode from here:
> http://hashcat.net/wiki/doku.php?id=mask_attack
Yes. I think this general syntax had been introduced in PasswordsPro:
http://www.insidepro.com/eng/passwordspro.shtml
"Mask Attack this attack is used when some information on the lost
password is known. To use the attack, make sure to specify the mask for
each character in the password to be recovered in the attack settings.
For mask characters you can use the conventional characters for the
standard or custom character sets ?u, ?d, ?2, etc. (see the "Character
Sets" tab in the program's settings)."
I vaguely recall seeing this before hashcat appeared. Unfortunately,
there doesn't appear to be much documentation on PasswordsPro's "mask
attack" on the web. I only found this very brief wiki page (and its
Russian counterpart):
http://wiki.insidepro.com/index.php/Mask_Attack
Anyhow, our mask mode needs to be mostly compatible with both hashcat's
and PasswordsPro's.
> The mask mode explained above is I guess slightly different from what we
> need for GPU. Alexander mentioned before we need to take into account
> the keys generated on cpu. Then use the mask to multiply the keys in GPU.
Yet I'd like us to implement the same kind of mask mode that those two
other crackers do. (We can then extend it in our own ways.)
The fact that some portions of the mask are to be iterated on the host
CPU and some other portions on the GPU (when supported by a given
format) does not prevent us from implementing the full mask mode
(regardless of the format's special support or lack thereof - that is,
this should only affect performance, but not functionality).
> To implement mask mode what are the parameters that we need to take from
> user? e.g keyspace size, mask etc ?
The mask.
> How do we apply the mask on the keyspace ? For example: when I get a key
> say 'abcdefgh'(generated on cpu) and a mask say '?d?d' at what position
> in the key are we supposed to apply the mask ? Do we append the mask or
> replace the charters at those positions ?
Let's say the user specified a mask of ?l?l?l?l?d?d (meaning four
lowercase letters followed by four digits). It is an implementation
detail which portion of this mask is to be iterated on the host CPU and
which (if any) on the GPU. Let's say a given format is most efficient
when it is permitted to iterated over the first one or two characters on
the GPU (it may declare so e.g. via new format->params fields). If so,
a smart mask mode implementation would let it do just that - iterate
over the first ?l?l on GPU, and it'd iterate over the rest of the chars
(for the remaining four positions) on the host CPU. When operating like
that, I suggest that we have the format overstrike the characters in
positions that we let it (the format) alter on its own. Yes, there will
be some overhead on sending those dummy characters to the GPU (e.g., we
send a string "aaword23" and the GPU tries all from "aa" to "zz" in the
first two positions, ignoring the initial "aa" in that string), but it
can easily be rendered negligible by having the GPU iterate over enough
character combinations per input password pattern.
Regarding the proposed set_mask() interface, please re-read:
http://www.openwall.com/lists/john-dev/2012/04/30/4
(My comment regarding using this from inside incremental mode was wrong,
though - I overlooked a show-stopper.)
http://www.openwall.com/lists/john-dev/2012/06/04/13
http://www.openwall.com/lists/john-dev/2012/08/07/13
My preference is that initially mask mode should be usable only on its
own. Being able to combine it with other modes (to achieve a hybrid
mode) is also highly desirable, but is not required for the initial
implementation. That said, here's what I posted on the topic before:
http://www.openwall.com/lists/john-dev/2012/04/30/10
However, if it's somehow easier for you to do things in the opposite
order - hybrid mode first, and mask mode on its own later - feel free
to do things in that way. (The command-line option should be --mask
either way, but hybrid mode would be achieved when it is used along with
another cracking mode.)
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.
