[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <17bb35b3e984e75df8674c9cdf5c2c96@smtp.hushmail.com>
Date: Fri, 28 Dec 2012 02:48:59 +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 2:20 , magnum <john.magnum@...hmail.com> wrote:
> 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:
>>> 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.
...
>>> 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.
I have committed an experimental patch for inc.c and mkv.c that set options.force_maxlength to the mode's max length, and call format->clear_keys(). Nothing is committed yet that actually make use of this but I do not predict any bad consequeces.
To try and actually use it, my experimental ntlmv2-opencl (far from being committed) got a proper done() that is used within the format, and (until the planned core changes) as an atexit() function. On a side-note: To make init() safe to call several times with that atexit() call, I had to add this:
static void init(...)
{
+ static int atexit_called = 0;
(...)
- atexit(done);
+ if (!atexit_called++)
+ atexit(done);
It took me a while in the debugger to figure that out... without this static variable, done() could end up being called twice or more at program exit, resulting in segfaults.
Anyway, the current clear_keys() look like this:
+/* Experimental support for re-initializing with a shorter max. length. This
+ is triggered by calls from Incremental or Markov modes. Technically we could
+ support increasing it too, though not beyond PLAINTEXT_LENGTH. */
+struct fmt_main fmt_opencl_NTLMv2;
+
+static void clear_keys(void)
+{
+ if (options.force_maxlength &&
+ ((options.force_maxlength + 1) < MAX(keybuf_size, 8 + 1))) {
+ unsigned char temp[SALT_SIZE_MAX];
+
+ memcpy(temp, challenge, SALT_SIZE_MAX);
+ done();
+ init(&fmt_opencl_NTLMv2);
+ set_salt(temp);
+ } else
+ memset(saved_key, 0, keybuf_size * global_work_size);
+}
This works but I'm not happy with it. It's ugly and slow. It really starts over from scratch: It will free and reallocate every single buffer and OpenCL resource and do a full re-tune to device. It will skew early reported performance figures (and we just got rid of that!).
Of course, I could do something much simpler: Add a kernel argument for keybuf_size and only transfer this in init() and possibly clear_keys(). But the kernel would become less optimized, work sizes would too (auto-tuned for other conditions) and buffer space would be wasted (affecting devices with little memory).
A totally different approach would be to "find out" before calling the format's init() that we are /going to/ run Incremental or Markov, and "find out" what max. length will be used. That might be an even uglier hack but it would mitigate the problems. Batch mode would be a cave-at though.
Already supported in latest git is to just add --max-length=N to the command line when using incremental or markov. This has none of these drawbacks. Maybe I should just drop this experiment (and possibly revert the changes in inc and mkv - OTOH they might come handy). I'll stash this and do something else for a while.
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.
