Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 14 Jul 2012 15:01:36 +0400
From: Solar Designer <>
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).


View attachment "john-" 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.