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.