Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 21 Jan 2012 20:08:47 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: dropping *_hash_0()

On 01/21/2012 07:40 PM, Solar Designer wrote:
...
> Thus, I propose that we drop 4-bit and add 29-bit hash values (for
> bitmaps; this corresponds to 27-bit for hash tables).  The maximum hash
> table size will then remain at 1 GB (per salt), although the
> corresponding threshold would be higher than we'd set it for direct hash
> tables (without bitmaps).
> 
> (29 also happens to be the number of significant bits in the first
> 32-bit half of binary tripcodes with the current code.)
> 
> This lets us reuse the same sets of 7 hash function pointers that we
> already have.  They will correspond to these return value sizes:
> 
> 8, 12, 16, 20, 24, 27, 29
> 
> I propose that we don't rename any functions.  Simply drop *_0() and add
> *_7(), so the new numbering will start with 1 (although array indices
> obviously start at 0).  Similarly, drop PASSWORD_HASH_SIZE_0 and
> PASSWORD_HASH_THRESHOLD_0, and add PASSWORD_HASH_SIZE_7 and
> PASSWORD_HASH_THRESHOLD_7 in params.h.
> 
> Any comments?

Sounds reasonable. But could we not have just one hash function, with an
added parameter for bit size? Like this

static int get_hash(int index, int bits)
{
	return crypt_key[index] & ((1<<bits)-1);
}

...and any format that need to take measures depending on size can do
that. I'm just brainstorming here: Perhaps this would be very bad for
bitslice formats, no matter how we do it?

> If a format is not updated, it will end up wasting memory.  To deal with
> this, we may introduce a new FMT_* flag that will indicate the use of
> the new sizes - but this flag will soon be set on all formats.  Do we
> need this complexity?

No, let's just fix all formats at once. However, if my idea above is
usable (in some form), it might be sensible to add a flag telling the
max size that the hash functions can return (for most formats it will be
the 32)

magnum

Powered by blists - more mailing lists

Your e-mail address:

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