Subject: Re: [boost] [optional] operator<(optional<T>, T) -- is it wrong?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-12-04 08:50:31
On 3 Dec 2014 at 11:24, Howard Hinnant wrote:
> > I just tried your script on Python 3.4 and got 0 candidate solutions
> > whereas 2.7 does yield solutions. I don't claim their chosen solution
> > is foolproof, but Python probably does see a lot more untrusted
> > inputs than probably C++ does. If there were a gaping security hole
> > there, we would surely have heard about it.
>
> More info on why this attack failed on Python 3.4:
>
> http://lwn.net/Articles/574761/
> https://www.python.org/dev/peps/pep-0456/
>
> These articles claim that Python 3.4 and forward have simply adopted SipHash.
Yes, you are correct. See http://lwn.net/Articles/574761/.
Python's adoption of SipHash as their core hash function wins it for
me, at least on 64 bit architectures only. Apparently it matches
FNV-1 for longer runs of bytes too, only on short strings does it
cost. Impressive.
> For anyone interested, there is a hash_append-compatible implementation
> of the SipHash24 variant here, in the files siphash.h/siphash.cpp:
I think this sufficiently important to warrant a separate N-paper
proposing a std::secure_hash<T> based on SipHash. Howard, you up for
that?
Niall
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/