[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20110503203459.GA26167@openwall.com>
Date: Wed, 4 May 2011 00:34:59 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: set_salt() using pointer
On Tue, May 03, 2011 at 08:42:26AM +0200, magnum wrote:
> I have seen some formats just copy the pointer fed to set_salt() and
> this is now done in mskrb5 and (my versions of) the NET*LM formats,
> saving a memcpy(). I also recommended Dhiru to do the same to ssh but
> before this gets too far I'd like to get this confirmed: Is this a
> "supported" behaviour? I have a vague feeling this could break things
> (in the future if not now) unless officially supported and I can't find
> it "documented". From what I [think I] know about john's internal
> workings I guess it's fine.
It wasn't meant to be supported. The speedup should be negligible when
crypt_all() processes a large enough number of candidate passwords.
Ideally, set_salt() would do some preprocessing of the salt, expanding
it into larger data structures that crypt_all() will use. This helps
when there's only one hash loaded for cracking - then set_salt() is done
just once, not once per crypt_all(). An example where it helps is
DES-based crypt(3). I understand that for some hash/cipher types no
such preprocessing of the salt is possible.
> There are plenty of other formats that could benefit from this too. For
> large salts this can make a significant boost.
Yes, but only if crypt_all() is very fast, which means that not only the
hash/cipher type is fast, but also crypt_all() processes too few
candidate passwords (and thus other overhead is incurred as well).
> Maybe a similar approach could be used in set_key() for formats that
> just use the key as-is and have a MAX_KEYS_PER_CRYPT of 1? I have not
> seen that in any existing format.
This also wasn't meant to be supported. We could declare it supported
now (if it doesn't break anything currently), but I see little need. If
the hash/cipher type is so fast that this makes a difference, then it
ought to use a much higher MAX_KEYS_PER_CRYPT.
That said, I don't really mind declaring both of these things supported
if they work fine technically now.
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.
