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.