[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8bc8f47f9694af877a040cc8c4e646b0@smtp.hushmail.com>
Date: Thu, 13 Dec 2012 02:20:10 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Run-time change of a format's max length
On 13 Dec, 2012, at 1:15 , Solar Designer <solar@...nwall.com> wrote:
> On Wed, Dec 12, 2012 at 01:33:11AM +0100, magnum wrote:
>> I'm in the process of tweaking ntlmv2-opencl. I now use partial binary transfers, and Unicode conversion on GPU. After that I could make the plaintext buffer variable-size. Like other fast formats it gets a significant boost from really short plaintext lengths, like 8.
>
> I think that this format would be badly impacted by the bottleneck even
> at lengths up to 8. The real fix is for us to implement on-GPU
> set_mask() as discussed this summer.
Sure. Even with these changes it does less than 550M MD5 plus 50 M MD4 per second with single salt. I guess the theoretical max is more than 15 times that... But I see this as one ingredience of many and it was a trivial change to the format (already done but not committed).
> Until we do, we only have these
> very limited workarounds. In this context, I am not sure how much
> effort we want to put into the workarounds. On the other hand, they
> would be helpful for some cracking modes even after we have set_mask().
I'm sure they will. Also, I really dislike when we impose limits we don't need to. This is the best of both worlds.
>> That is a severe limit though, and you wouldn't want to recompile for different lengths. So a better option is to default to 27 characters, but honor the --length option of Jumbo (which merely decreases format->params.plaintext_length).
>
> Shouldn't this option be called --max-length instead, and we'd have
> --min-length too?
That has crossed my mind too, I should change it. This would let us run incremental with a length range without having to define a temporary in john.conf. Is there any other use of min lengths? Markov mode perhaps.
> As to plaintext_length, I intend to add a flag that would indicate
> whether truncation at this length occurs in actual use of the target
> systems (that use hashes of this type) or whether it's a limitation of
> the format as implemented in JtR. There's a third possibility - the
> target systems do not permit longer passwords - but for our needs this
> is the same as JtR limitation, I think (except for documentation /
> reporting, maybe). To summarize, there are three possibilities:
>
> 1. Target systems truncate at plaintext_length.
>
> 2. JtR does not support longer than plaintext_length even though target
> systems do.
>
> 3. Target systems do not permit longer than plaintext_length.
>
> When processing an overly long candidate password (one that would exceed
> plaintext_length), JtR should truncate it if #1 is true or skip it if #2
> or #3 are true. This logic is not currently implemented (JtR always
> truncates), but I think we should implement it.
I agree.
> In this context, if --max-length is specified and results in the value
> of plaintext_length being lowered, this should be treated the same as
> #2/#3 (longer passwords skipped). It should not result in truncation.
Right.
>> If we let eg. incremental mode alter format->params.plaintext_length (that is, tell the format about incremental's MaxLen), we will automatically use the best possible speed. So how do we accomplish this? Just change it? Well, the problem is that the format inits long before incremental does.
>
> Yes, maybe we need to introduce a new interface - or rather, just a new
> convention - that plaintext_length may be reduced by a cracking mode, in
> which case the format _may_ (but is not required) to make use of this
> info and actually stop supporting longer passwords (that it previously
> could support). I guess it'd check for the possibly-lowered
> plaintext_length at the start of crypt_all() and call a re-init function
> if so. With GPU formats, there's a lot of work being done per
> crypt_all() call, so this extra if/call will probably not cost much.
Yes. Hopefully we can do with just a convention.
> Alternatively, we could introduce a reinit() method or stipulate that
> init() may be called a second time. In fact, the latter is happening
> now for formats that share an init() implementation - the dynamic
> formats, some DES-based hash formats.
Such change to init() would mean many formats need a touch. Still, I think it's better than having a separate reinit().
>> Perhaps I could implement a check in clear_keys() that detects the change, and re-inits whatever is needed. That's the best I can think of right now (except for more core changes). This would theoretically even support adapting to the shorter length *within* an incremental run but that will be too slow to be useful I guess... hmmm but it might be useful for batch mode, between modes.
>
> Yes, you're right about these aspects. And yes, clear_keys() may be a
> better place than crypt_all().
I'll try clear_keys() and see how it works out. Maybe this is all that's needed, and it will keep the changes in the cracking modes to a minimum.
magnum
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.
