[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120714173446.GA1633@openwall.com>
Date: Sat, 14 Jul 2012 21:34:46 +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
On Sat, Jul 14, 2012 at 11:16:34AM -0500, jfoug wrote:
> 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 think that starting with a more limited interface and implementation
and then enhancing it with separate changes/commits is fine. As I wrote
earlier, I did not particularly like some specifics of the source()
interface you were using. So I opted for the simpler thing first, with
intent to enhance it in a slightly different way from what you did.
Doesn't this simpler interface cover all use cases you currently have in
bleeding? I thought you were not using this for any salted hashes yet,
were you?
Besides, with salted hashes we'd normally have a unique salt for almost
every hash (unless the system generated salts poorly, which does
happen), so we'd have a struct db_salt allocated anyway and thus the
savings from not keeping the source string are relatively smaller.
> 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.
Yes. Note that I did not implement hot/cold yet, I merely considered it
as a likely enhancement, thus only making changes that would be
compatible with that enhancement later. What I implemented so far is
"inline" storage of very small binary hashes (up to 64 bits in a 64-bit
John build) by reusing the "char *source" pointer to store them in
formats where we don't need that pointer for its original purpose. This
currently works for LM hashes and it should work for a few more in jumbo
(old MySQL, anything else?), but it wouldn't work e.g. for NTLM.
Hot/cold separation is still planned, to be used for hashes larger than
the machine's word size.
One idea is to revise struct db_password such that it would either have
explicit inline space for the hot portion (perhaps a 32-bit field) or
have the hot portion right before or right after it (a fixed offset
relative to struct start either way). "Right before" might be better
since we already have some fields "right after" - or rather, they're
struct fields for which we don't always allocate memory (sometimes the
allocation is smaller than the declared struct size). The cold portion
would need to be accessed through a pointer, which would be a struct
field - or it can be an integer offset relative to the struct's address
(so that we'd be able to make it 32-bit even in a 64-bit build), but
that's tricky. Maybe those "right after" fields I mentioned should be
moved to the cold portion (then it won't be limited to being a portion
of the ciphertext).
> 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
There's almost always either a better way to do something or a tradeoff
involved, or both.
> thus jumbo will be hamstrung.
I don't feel that my initial source() interface reduces the current
functionality of bleeding in any way. Does it? Please be specific if so.
Thanks,
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.
