Add a build option to use blake2 prehashing for ed25519 signatures

[neilmayhew]

The default prehashing algorithm is sha512 but the ed25519 specification allows alternative hash algorithms to be used, and some crypto applications are now using blake2.

Ideally this would be a runtime choice, but that:

• has a performance impact;
• would involve adding to the external API;
• would take a lot more work to implement.

I think it's rare that a library client would need to use multiple types of hashing with ed25519.

Unfortunately, I couldn't find any readily available test vectors for ed25519 with blake2 so I've disabled those tests when the flag is on.

---

This change is 

[ocheron]

I think it's rare that a library client would need to use multiple types of hashing with ed25519.

I'm not so sure about this. Nowdays it's common to send/receive through web services. X.509 and TLS use Ed25519 with SHA-512.

The project goal is to pack together multiple algorithms in a single package. Forcing to choose with a compile flag is difficult to manage in transitively dependant packages.

[neilmayhew]

X.509 and TLS use Ed25519 with SHA-512.

Yes, this is typical but not universal. Our application needs to interact with a third-party protocol that uses Blake2 and we need a way to generate and validate signatures.

The project goal is to pack together multiple algorithms in a single package.

Cryptonite already has the necessary code, but the pieces aren't exposed externally, due to the way the upstream ed25519-donna code has chosen to implement the choice of hash algorithm, ie at compile time through user-supplied functions with hardcoded names. Allowing the algorithm to be chosen at runtime would require significant changes to the C code.

Forcing to choose with a compile flag is difficult to manage in transitively dependant packages.

This is a good point, and I hadn't thought about that. It doesn't seem to cause a problem in our application, but it could do for others. However, having the flag available doesn't itself cause problems, so applications could enable the flag only if it's helpful for them. If it's not helpful, they're in the same position they would be if the flag didn't exist.

At the moment, our only solution is to use a forked version of cryptonite. As well as being undesirable for us, it's not good for cryptonite if there are various patched versions in use. I think it's much better if this variation is available centrally, but only enabled for those applications that actually need it.

[vincenthz]

This is a bit tricky to expose the hash function of a C implementation, we don't have the same capability in term of expressibility (like passing a hash function closure with additional size constraint).

The only way I can imagine to reconcile this smoothly, would "duplicate" the C code and expose different entry points for the blake2'ed ed25519, although that wouldn't scale very well .. specially considering that now blake3 is also out, or someone might like SHA3 also.

[vincenthz]

archiving repository