feat: implement Digest for DomainSeparatedHasher

[stringhandler]

Implements Digest for DomainSeparatedHasher with a blank default label
Deleted GenericHashDomain

Motivation

This means you can use a DomainSeparatedHasher in any function that already uses Digest. Unfortunately, the label must be blank, so the domain should be different for struct.

I also added a macro hashing_domain for creating domains quickly (e.g. for tests)

hash_domain!(MyDemoHasher, "macro.test");
// Generates

 pub struct MyDemoHasher {}

        impl DomainSeparation for MyDemoHasher {
            fn version() -> u8 {
                1
            }

            fn domain() -> &'static str {
                "macro.test"
            }
        }   

   

After adding the hash_domain macro it is now easy enough to create a new domain when you need it, removing the need for GenericHashDomain. I found that devs were trying to build on top of it instead of creating new domains, so IMO it's more confusing keeping it in

UPDATE: Removed GenericHashDomain
UPDATE: Added create_hasher! macro

[CjS77]

The digest crate already offers a default impl for

impl<D: FixedOutput + Default + Update + HashMarker> Digest for D 

Is this intended to be a stopgap so digest is available while we look at impl the other trait bounds?

[stringhandler]

I suppose I could implement Update and Reset individually instead, but I am not sure that covers all of them

[stringhandler]

I tried implementing them individually, but because we need to push a prefix when we reset, the Reset needs Update, and FixedOutput needs Reset and it ended up being a lot more code than implementing the whole of Digest.

[hansieodendaal]

Hi @stringhandler, LGTM, but please consider to merge this PR into your branch.

[hansieodendaal]

I think it is important to show that this equality only holds if an empty label is supplied for the same hash domain, thus add a failing test for a hasher with a label.

Otherwise LGTM

[sdbondi]

Implementing Digest and the hash_domain! macro is a great improvement - I have a concern about how create_hasher! should be used.

[sdbondi]

What is __TempHashDomain?

[sdbondi]

My only concern about create_hasher! is that users will duplicate the domain separation domain label.

fn hash_foo(foo:&Foo) -> Hash {
   let hasher = create_hasher!(Blake256, FooBarHasher, "com.foobar", "foo");
   hasher.chain(foo.as_bytes()).finalize()
}

fn hash_bar(bar:&Bar) -> Hash {
   let hasher = create_hasher!(Blake256, FooBarHasher, "com.foobar", "bar");
   hasher.chain(bar.as_bytes()).finalize()
}

Perhaps create_hasher! should take in a domain type?

define_hash_domain!(FooBarHashDomain, "com.foobar");

fn hash_foo(foo:&Foo) -> Hash {
   let hasher = create_hasher!(Blake256, FooBarHashDomain, "foo");
   hasher.chain(foo.as_bytes()).finalize()
}

fn hash_bar(bar:&Bar) -> Hash {
   let hasher = create_hasher!(Blake256, FooBarHashDomain, "bar");
   hasher.chain(bar.as_bytes()).finalize()
}

[stringhandler]

The macro isn't really needed unless you are creating a new struct. (The DomainSeparation).

In your second example you can just create a method

fn create_hasher<D:Digest, Dom:DomainSeparation>(label: &'static str) -> ...

[stringhandler]

Here's an example of create_hasher!, but I agree it's probably better to leave it out and create the method.

     create_hasher!(Blake2b, "com.tari.cipher_seed_mac")
            .chain(plaintext.clone())
            .chain([CIPHER_SEED_VERSION])
            .chain(self.salt)
            .chain(passphrase.as_bytes())
            .finalize()

[agubarev]

same concern as @sdbondi, it's nice to add a suggestive comment not the use the long form macro create_hasher!(), maybe add another macro next to it, that would differ by name instead of only arguments

[agubarev]

users might not even notice that calling the long form in multiple places will define nested structs in different places where it's called, which will work of course, because the data will match, but could be unintentional duplication