Re: [boost] Crypto/hashes library?

Subject: Re: [boost] Crypto/hashes library?
From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2017-09-07 20:07:45

On Sep 7, 2017, at 12:40 PM, Vinnie Falco via Boost <boost_at_[hidden]> wrote:
> 
> On Thu, Sep 7, 2017 at 9:26 AM, Howard Hinnant via Boost
> <boost_at_[hidden]> wrote:
>> endian taken into account here:
> 
> I use endianness only as an easily understood example of an issue that
> makes the needs of a cryptographic hash interface different from an
> unordered container hash interface. There are other issues, which
> require a move involved discussion than I think is appropriate in this
> thread. For example, we cannot have distinct cryptographic and
> non-cryptographic serialization algorithms for the same type (using
> n3980).

Demo for distinct serialization algorithms for varying hashers:

    #include "hash_append.h"
    #include "sha256.h"
    #include "fnv1a.h"
    #include <iostream>

    class X
    {
        std::array<unsigned char, 32> d_{};
    public:
        friend void hash_append(acme::sha256& h, X const& x)
        {
            std::cout << "hash with sha256: ";
            xstd::hash_append(h, x.d_);
        }

        template <class Hasher>
        friend void hash_append(Hasher& h, X const& x)
        {
            std::cout << "hash with everything else: ";
            xstd::hash_append(h, x.d_, x.d_.size());
        }
    };

    int
    main()
    {
        X x;
        xstd::uhash<acme::fnv1a> h1;
        std::cout << h1(x) << '\n';
        xstd::uhash<acme::sha256> h2;
        for (auto const& i : h2(x))
            std::cout << std::hex << (unsigned)i;
        std::cout << '\n';
    }

Output:

    hash with everything else: 7024978713738287141
    hash with sha256: 66687aadf862bd776c8fc18b8e9f8e2089714856ee233b3902a591dd5f2925

> 
> The bottom line is that n3980 needs to go through more iteration and
> study with respect to its usage for cryptographic hash algorithms
> before we can state that the interface is well suited for it.

I welcome and encourage more study and discussion in any context, thread or list.

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.  Admittedly, the latest proposal (N3980) is sorely in need of updating and likely doesn’t have the latest details of the implementation at https://github.com/HowardHinnant/hash_append .  And thanks for the shout-out to this lib earlier in this thread.

Howard