[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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-1.7.9.4+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.
