Re: [boost] [optional] operator<(optional<T>, T) -- is it wrong?

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/