VRF crate

[carloskiki]

Adding traits for Verifiable Random Functions. See #1728.

The vrf name on crates.io is taken. The current crate under this name seems unmaintained, the last commit being 3 years ago.

The exact structure of the traits is not defined yet, I'm mostly looking for some input until we resolve the crate name and have some confidence that we have a good interface.

[tarcieri]

For a crate name, verifiable-random-function would fit our naming scheme

[newpavlov]

We could ask in the vrf repo about potential crate ownership transfer. Another option is to use something like crypto-vrf.

[carloskiki]

We could ask in the vrf repo about potential crate ownership transfer.

Yes, the maintainers seem active on github. If we decide to try getting the name vrf, let me know if I should be the one contacting them. I think if a maintainer of RustCrypto does then we have more credibility but I'm open to doing it.

[carloskiki]

Otherwise, we could abuse the Signer and Verifier traits, and implement them with a type parameter that implements proof (this is very likely not a good idea). We wouldn't need the Prover and Verifier traits. Or maybe we just want the Prover trait and we reuse the Verifier trait from signature, because all vrfs that I know of are based on asymmetric signatures.

[tarcieri]

If this is intended to be pi in RFC9381 parlance it would be nice to note that in the rustdoc and also, what about serializing/deserializing pi itself?

[carloskiki]

Yes, I did not write any doc comments yet, because I'm not sure about the design and I want my ideas to mature a bit. But indeed, this is pi, which means we should be able to serialize and deserialize it. This would be similar to SignatureEncoding in the signature crate.

Having both crates being so similar makes we wonder whether we really need a new crate for this. Using the Signer trait to serve as a Prover is an abuse of language, but both traits are the same semantically and the Verifier trait would be identical in both crates. SignatureEncoding also maps to vrfs because we need encoding/decoding for the proof. The only thing we are missing from the signature crate would be a way of hashing the proof (VRF_proof_to_hash in RFC9381).

[tarcieri]

Yes, traits from the signature crate could be used instead if we want. If the only thing that's really needed is a trait for VRF_proof_to_hash, we could potentially just add that to signature.

The nice thing about a separate crate is it could have stricter bounds which would make things a bit easier to use. Instead of having to bound on Signature: SignatureEncoding + VrfProofToHash (or whatever), those bounds could simply be automatic (in addition to the trait names being more idiomatic for VRFs)

[carloskiki]

Yes, traits from the signature crate could be used instead if we want. If the only thing that's really needed is a trait for VRF_proof_to_hash, we could potentially just add that to signature.

The nice thing about a separate crate is it could have stricter bounds which would make things a bit easier to use. Instead of having to bound on Signature: SignatureEncoding + VrfProofToHash (or whatever), those bounds could simply be automatic (in addition to the trait names being more idiomatic for VRFs)

After some time off, I think what we should do is use the Verifier trait from the signature crate, and keep the Proof and Prover traits.

A question I would like answered: should we add VRFs as a module in signature (perhaps behind a feature) or should we keep it in a separate crate?

[tarcieri]

Since signature is a post-1.0 crate I think it would be nice to prove it out in a separate crate. It could eventually be merged.

[tarcieri]

FYI: the vrf crate seems to be getting regular updates, so I didn't attempt to contact them

[carloskiki]

Indeed. I was thinking we could group vrf, oprf, voprf, etc. under a random-function crate.

[carloskiki]

I will close this for the moment, as I don't have plans to make this move forward in the immediate future.

[tarcieri]

@carloskiki FWIW I have intended to eventually get around to this, but probably some time after we've done new stable releases of everything else