Re: [boost] Crypto/hashes library?

Subject: Re: [boost] Crypto/hashes library?
From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2017-09-07 20:51:02

On Thu, Sep 7, 2017 at 1:07 PM, Howard Hinnant <howard.hinnant_at_[hidden]> wrote:
> 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.