Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ