Re: [boost] Crypto/hashes library?

7 Sep 2017

      On Sep 7, 2017, at 12:40 PM, Vinnie Falco via Boost <boost@lists.boost.org> wrote:
...
On Thu, Sep 7, 2017 at 9:26 AM, Howard Hinnant via Boost
<boost@lists.boost.org> 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