[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <002101cd61dc$0a490770$1edb1650$@net>
Date: Sat, 14 Jul 2012 11:16:34 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: magnum-jumbo and magnum-bleeding (NOT J7), and the source() function
>From: Solar Designer [mailto:solar@...nwall.com]
>
>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
>>
>> 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
Lol, magnum and I worked through many of these items already, and on jumbo,
there are even MORE tricky situations than in core, but you have pretty much
reverted back to one of our earlier attempts that was significantly more
limited in usefulness than what we obtained in the end.
I do like the hot/cold addition. This keeps the hot part of binary (which
source() requires to be fully available) in a much smaller working set in
the core loop, which was one shortcoming of my original version.
>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.
Ok, you have enhanced the interface in some areas, but reduced functionality
in other areas. I just question if there is a better way and interface to
do this, but now, it is 'locked down', due to being implanted in core, and
thus jumbo will be hamstrung.
>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
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.
