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

Subject: Re: [boost] [optional] operator<(optional<T>, T) -- is it wrong?
From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2014-12-04 10:35:06

On Dec 4, 2014, at 8:50 AM, Niall Douglas <s_sourceforge_at_[hidden]> 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 MyClass’s 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.

Howard