[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Wed, 12 Dec 2012 01:33:11 +0100
From: magnum <john.magnum@...hmail.com>
To: "john-dev@...ts.openwall.com" <john-dev@...ts.openwall.com>
Subject: Run-time change of a format's max length
Solar,
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.
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). This I can (and will) do right now, in init(). But here comes the punch line, and the question:
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.
Any ideas?
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.
