[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110329162248.GC16399@openwall.com>
Date: Tue, 29 Mar 2011 20:22:48 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: john scalability
On Mon, Mar 28, 2011 at 09:19:20PM +0200, magnum wrote:
> So here it is, suggested for the Jumbo. This patches all formats that
> had only three sizes (except AFS), extending them to have five.
Thanks!
A related concern, though, is that the self-tests only check that the
values are in range - they don't check for full usage of the range, nor
for uniform distribution. So it is easy to have a bug where a large
hash table would be allocated, but only a subset of its hash buckets
would ever be in use. This is why I did not bother spending my time on
"legacy" code such as DES_std.h and AFS_fmt.c, which would then take a
considerable amount of time to fully test (with different compile-time
settings, even).
> The bunch of formats that does not have *any* hash functions, are not
> fixed here. I suppose some of them should be looked at - ...
Yes, all of them, please.
Also, all salted ones should have a salt_hash function.
> Many of the formats in this patch will not likely ever benfit from the
> larger sizes but I can't see how this would ever do any harm either.
If the hash functions don't actually use the full range (see above),
then it might increase memory usage while not improving performance.
However, when there are no bugs of this nature, then it is desirable to
have all hash table sizes supported.
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.
