[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20120121192853.GA13999@openwall.com>
Date: Sat, 21 Jan 2012 23:28:53 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: dropping *_hash_0()
On Sat, Jan 21, 2012 at 08:08:47PM +0100, magnum wrote:
> ... 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?
Of course I had thought of this - both years ago (before I introduced
the three hash functions for 4, 8, 12 bits in 1990s) and again this time
(before posting the proposal that I did post). You're right - my
concern is that this will have performance impact, especially for formats
where these functions are non-trivial. Specialized versions of them are
faster. This would be partially mitigated by the lack of granularity in
bitmap and hash table sizes (so they could be chosen possibly more
optimally), but I doubt that this will be enough.
In fact, for bitslice DES I am planning to have as many as 56 versions
of the code, with some compiler magic to avoid writing this all in the
source code (I tested this as a hack already). That's 7 functions times
8 versions of code for each for different bit layer indices.
We could introduce optional support for generic hash functions like what
you describe, though - to be used for formats where this doesn't
significantly affect the overall speed (such as for slow hashes).
My other thoughts on merging some of this stuff into crypt_all() may
affect the overall approach to this, though.
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.
