On Thu, Sep 7, 2017 at 1:07 PM, Howard Hinnant
Demo for distinct serialization algorithms for varying hashers: ... friend void hash_append(acme::sha256& h, X const& x)
Burdening a user defined type with the requirement to know exactly which cryptographic hash functions will be used with it ahead of time, and adjusting the serialization algorithm to compensate - is precisely the style which n3980 aims to prevent.
My only motivation here is to dispel mistaken believes that the current hash_append infrastructure can not handle issues such as endian or alternate serialization algorithms for different hashers.
The problem with the way endianness is handled in n3980 is that it treats it as a property of the hash algorithm, when it is actually a property of the protocol which makes the use of a cryptographic hash function. For example, imagine we have two protocols X and Y. Each defines some object lets call it "Customer", with various fields including unsigned or multi-precision integers. Each protocol also calculates the SHA256 digest of the serialized representation of a Customer. The question arises, when a Customer is serialized, what endianness is used for the integers? The case where protocols X and Y each choose a different endianness in the specification makes the current approach to endianness in n3980 less than ideal. The problem is that n3980 was not designed from the ground up with the needs of cryptographic hashing in mind, so the interface is not a perfect match for that use-case.