On Sat, Sep 17, 2016 at 6:35 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:

> Hi all,
> On Sat, Sep 17, 2016 at 5:13 PM, Stanislav Malyshev <smalys...@gmail.com>
> wrote:
> >> Significant degradation?
> >>
> >> SipHash 1-3 is almost as fast as HashDoS-vulnerable hash
> >> functions: https://github.com/funny-falcon/funny_hash
> >
> > I see on this link comparison to Murmur3 - but that's not the function
> > we are using. Is there a comparison to PHP one?
> Unfortunately, SipHash was a lot slower. BJB hash is simple and super
> fast, even google's CityHash was a lot slower when I tested. (Sorry I
> don't keep the number)
> I think we are better to limit max collisions.
> I'm +1 for Nikita's proposal does this.
> Regards,
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net

As long as the pro‚Äčblem gets solved, I'm not in favor of any particular

I do find this amusing, though: the author of djb3 was Daniel J Bernstein,
who also helped develop SipHash. I guess non-cryptographic hash functions
are a small world.


- Do you think your proposed strategy can solve this problem entirely
without dropping djb3?
- Would randomization still help as a defense-in-depth?

To elaborate on the second question: even a 4-byte prefix for the hash
function inputs that's randomly generated at $appropriateIntervalHere might
make intentional collisions harder to trigger. (Then again, maybe not! The
underlying structure of djb3 isn't exactly cryptographic.)

To be clear, "Yes this is entirely solved without switching away from djb"
+ "No, randomization just hurts opcache and doesn't buy us any security"
are an acceptable set of answers to these questions. I just wanted to ask.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>

Reply via email to