Ed25519 sign/verify builtins

[pchiusano]

This is needed for many applications (Discord webhook auth came up), and I don't think we should try to implement in pure Unison right now, same as other crypto primitives.

-- sign.impl secretKey publicKey message
crypto.Ed25519.sign.impl : Bytes -> Bytes -> Bytes -> Either Failure Bytes

-- verify.impl publicKey message signature
crypto.Ed25519.verify.impl : Bytes -> Bytes -> Bytes -> Either Failure Bool

The Failure is because not all Bytes correspond to a valid public key or secret key.

In base, I'd wrap these in more convenient typed interfaces:

-- SecretKey, PublicKey, and Signature are just newtypes around Bytes

crypto.Ed25519.sign : SecretKey -> PublicKey -> Bytes ->{Exception} Signature

crypto.Ed25519.verify : PublicKey -> Bytes -> Signature ->{Exception} Boolean 

It might not be worth newtyping SecretKey, PublicKey, and Signature, depending on taste. There's also the question of whether we have a separate newtype for all the different public key algos, when more are added.

Following:

https://hackage.haskell.org/package/cryptonite-0.5/docs/Crypto-PubKey-Ed25519.html#t:PublicKey

@jaredly does this seem easy to implement in Racket?

[jaredly]

So the racket library crypto supports es25519, but it's LGPL. It looks like that library uses libdecaf under the hood, which shouldn't be too hard to write FFI for

[jaredly]

Update on this: turns out openssl's libcrypto supports es25519, so I'm doing FFI to that.

[jaredly]

@pchiusano ok I've got signature generation working, but I have a question: the unison impl requires both the seed and the public key for signature generation, but the public key can be generated from the signature, and libcrypto only requires the seed. Should I just ignore the public key argument?

[etorreborre]

@pchiusano @jaredly would it be possible to extend this support to RSA signatures 🙏 ?