New Java+PHP user

[james@mastros.biz]

On Tue, Oct 21, 2003 at 05:35:02PM -0700, Brad Fitzpatrick wrote:
> Or better, provide an option:  "standard_hash" or something, be that what
> the Perl module uses, or crc32, or the Perl hash.  So modules can either
> support the standard_hash option or not... they could use their own that's
> faster (built into the language, or written in C), and only use the slower
> standard hash if requested.
I'd like to suggest, rather strongly, that you not use the perl hash, or at
the very least, that you don't simply call the perl function that does it,
even on the perl client.

The reason is that there's a known attack for it at
http://www.cs.rice.edu/~scrosby/hash/.  Unfornatly, most hashing algorithms
can be effected by this, but at the very least, using a different algo means
that the input keys need to be recomputed for the modified algo.  There's
been at least two attempts to fix this in perl.  The first creates a new
random hash key on every start of perl, thus keeping the attacker from
knowing what keys will produce O(n^2) behivior (hash lookup is normaly O(log
n), IIRC).  Unfornatly, that has binary incompatibility problems for perl.
That's not a problem here, but it does mean extending the protocol to tell
the clients what key to use on initial connect, and making sure the servers
all agree on it.  (I'm assuming that the servers are less and longer-lived
then the clients here.)

The other method is to change parameters only in cases where we appear to be
under attack (or, put alternatively, where we're getting poor performance
from the current parameters).  Unfornatly, unless all the clients know to
change paramters at the same time, that method is unavailable to us.

Also, BTW, the implementation of the hashing in the perl client could be
sped up quite a bit.  I'm not sure if that'd be premature optimization.
     
       Thanks,
       -=- James Mastros