On 4 Dec 2014 at 10:35, Howard Hinnant wrote:
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?
Thanks, but no, I don´t think I can do that.
SipHash isn´t the ultimate answer in hash security. It is the front line in a never ending war. SipHash arrived on the scene two years ago. I didn´t learn of it until a year ago. Many people are just learning of it now. We can´t possibly standardize it for another 3 years.
The standardization process is way too slow for this kind of thing. In order to be effective, the standard needs to enable the programmer to choose the latest available weaponry. Because by the time we standardize algorithm X as the algorithm of choice in std::secure_hash<T>, odds are going to be good that it has already been attacked, and made obsolete by a better algorithm.
The most I could back is offering SipHash as one of the customizable HashAlgorithms that could be used in hash_append.
This is worlds different than std::secure_hash<T>, because when you author hash support for MyClass, std::secure_hash<MyClass> locks you in to a std-supplied algorithm, be it SipHash, or something else. That is bad. But when you instead write your hash support in terms of a hash_append which is templated on HashAlgorithm, then you can use SipHash, or any other hashing algorithm, without ever having to revisit MyClassTMs hash support code again.
Subsequently this means that when your unordered_set<MyClass> is attacked, you can do something about it (overnight!) without waiting years for a committee to come to your rescue.
You seem to be assuming that a std::secure_hash would be implemented inline. It need not be so, it could be implemented via an extern implementation in a shared library, and therefore an OS security update could push replacements. I'd assume that wouldn't fly as code depending on the ordering of an unordered map would break, so the committee would say no. So that brings us back to your alternative. Howard are there good reasons why your reference library for N3980 hasn't been submitted to Boost for review and inclusion? With something like my forthcoming BindLib a single code base can be dual use, so both compilable as a Boost module and as a totally independent standalone library. I'd also think that N3645 would swing more weight if already implemented and used within Boost. Long road to implementing that though. And we could do with better map STL container design anyway. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/