[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120430101743.GA7865@openwall.com>
Date: Mon, 30 Apr 2012 14:17:43 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Password Generation on GPU
Hi Frank,
Thank you for your comments.
On Mon, Apr 30, 2012 at 10:57:36AM +0200, Frank Dittrich wrote:
> I'm afraid that part of this might be on topic in john-users.
> But I hesitate to cross-post (because I am not sure which followup-to
> would be better).
Let's keep this on john-dev because it is fairly obvious (at least to me
and in my opinion) what the users will want, and the question is how and
whether to implement it. I expect that most of the discussion will be
about JtR internals (what can and what cannot be implemented easily).
> On 04/30/2012 06:32 AM, Solar Designer wrote:
> > 4. We may try to make some other cracking modes set_mask()-aware as well.
> >
> > Incremental mode is potentially capable of using this interface for the
> > last character position,
I overlooked one important detail here: this would only work if
set_mask() may be called multiple times per one crypt_all() call. In
fact, for the above it'd need to be called as often as set_key() is - so
maybe we'd want to have extra parameters to set_key() instead of a
separate set_mask() method then. However, I think we'll choose not to
allow for multiple set_mask() calls per crypt_all(), so the incremental
mode hack would not be possible (unfortunately), or maybe we'd allow
formats to declare support for multiple set_mask() calls per crypt_all()
as a separate optional feature.
> > except when it has the last character index
> > fixed (and thus alters character indices in other positions only). For
> > example, when trying passwords of length 8, incremental mode would thus
> > be able to use set_mask() 87.5% of the time in a long-running session.
> > (The growing and reducing c/s rate may be confusing, though.)
>
> You could even use it for the last character as well, if you add 0x00 to
> the mask.
I think you're speaking of something totally different from what I had
in mind here. I was referring to the way incremental mode enumerates
all possible character indices without overlaps. The algorithm that it
uses requires that at every stage it keeps the character index in one
position fixed, only incrementing the rest of the indices. When that
fixed index position happens to be the very last one, then we can't use
set_mask() because none of the remaining characters are determined with
a simple single-dimensional charset. In other cases, once all but the
last character are determined, we easily obtain the charset for the last
position (this is chars_cache in current inc_key_loop() code), so
instead of going over it in inc.c, we can call set_mask() on it and call
set_key() on the preceding string. You may notice how the "goto
update_last;" statement is only reached in the "fixed < length" case.
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.
