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/