Date: Sat, 14 Jul 2012 15:01:36 +0400 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: magnum-jumbo and magnum-bleeding (NOT J7), and the source() function Jim, all - On Tue, Jul 10, 2012 at 03:24:57PM +0400, Solar Designer wrote: > On Mon, Jul 09, 2012 at 05:46:31PM -0500, jfoug wrote: > > I do think the interface for source() (or get_source(), or foo_bar() or > > whatever) is good. Passing in the db_password structure pointer, and then > > 'using' the salt pointer in multiple ways, makes calling source() very easy > > to do, almost a direct replacement for the original pw->source pointer, AND > > saves memory, in not wasting space even for another pointer. > > My tentative plan is to reuse the pw->source pointer for the "cold" > portion of the binary, when we do introduce the hot/cold split. I do > not see why you need it for storing the salt. I think that source() > should accept "void *binary" and "void *salt" instead of "struct > db_password *". Yes, this is two parameters to pass instead of one, > but so what. We're not calling source() from so many places that the > extra parameter would make the source code much less readable. In fact, > preserving the separation between a "format" and a "database" is good. > I might deviate from this separation in another place, but that's for a > specific good reason, and it'd be an exception that proves the rule. ;-) > I don't see a good reason like that for source(). This turned out to be trickier than I had expected since there are places in loader.c where we have a binary, but no corresponding salt (we can find it with an extra loop, though). For now, I chose to implement source() for saltless hashes only. For salted hashes, it currently ought to be fmt_default_source(), which simply returns the source passed into it verbatim. I have not yet implemented the hot/cold thing. Instead, I am currently reusing the source pointer to hold the binary value when it fits into that field (like for LM hashes on a 64-bit machine). Attached is a patch demonstrating these changes (relative to the patch introducing prepare() that I posted yesterday). I tested this on 10 million of LM hashes. Memory usage reduced from 1040 MB to 805 MB, the speed appears to have remained unchanged (maybe there is a speed difference for smaller hash counts, like 100k). Alexander View attachment "john-126.96.36.199+prepare-source-3.diff" of type "text/plain" (14270 bytes)
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.