Use Blake2b instead of SHA about mithril

[abakst]

This question may just be an artifact of our old hash_to_curve implementation. Let's return to this issue after #5 to see if we need to resolve it.

[markulf]

Is there a benefit from not using whatever cardano is using? Is cardano calling a rust or a C library? (libsodium)

Ideally hash functions should be easy to replace. Cautionary tale of MD5 being very hard to remove reliably from legacy software.

[abakst]

Indeed it is very easy to change the hash. It is only fixed by our implementation in two places (one for the dense mapping, one for hash_to_curve, so these choices are somewhat independent). We're also parameterized by the hashing strategy for the Merkle Tree (our tests use Sha3 but that can be changed easily as well).

We're actually only relying on Blake2b/Sha3 implementing traits from digest, so it should be straightforward to swap out another hash in msp::eval and hash_to_curve. If you'd like we can use something other than Blake2b, presumably most hashes would have a similar interface even if they do not implement these traits.

[iquerejeta]

We used SHA because the Blake2b library we use does not support output lengths we need - error at runtime for length 300+.

could you give an example of where it breaks at runtime? I'm guessing that length 300+ is bits, right? not bytes? If I recall correctly, we don't need output lengths higher than 300 bytes, but I might be missing something. I made a PR #24 removing sha3, and it seems to work for now.

Blake2b is good for now. It is our default choice in Cardano