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 problem gets solved, I'm not in favor of any particular solution. 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. Nikita: - 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/>
