Crypto Configuration / CipherSuite Trait

[kevinlewi]

Right now, we have VRFs which can be instantiated and supplied as a generic for a Directory, and we use feature-gating for selecting the underlying hash function.

In the future, I'd like to also introduce more configurability for the cryptographic operations in AKD -- for instance, the function which derives a parent node's root hash from its children, how we produce commitments to the AKD values, etc.

Most of these operations are contained in this file for now: https://github.com/facebook/akd/blob/main/akd_core/src/crypto.rs but in order to support more flexibility for other implementations of these functions, I'm envisioning that we can try to bundle these implementations into some sort of crypto configuration trait or ciphersuite syntax.

Examples:

Introduce a new trait, something like:

trait CipherSuite { 
  type VRF: VRF,
  type Hash: Hash,
  type TreeHash: TreeHash, // would contain a bunch of functions that are currently in akd_core/src/crypto.rs right now, probably needs a better name
}

And then, an instantiation of this trait could be specified when initializing a directory, rather than passing in a VRF and feature-gating with a hash function like we do now. So for instance, we could define

struct WhatsAppConfiguration;
impl CipherSuite for WhatsAppConfiguration {
  type VRF: HardCodedAkdVrf,
  type Hash: SHA256,
  type TreeHash: ...,
}

with the idea that consumers which would like to re-use these configurations could do so with ease (we could make WhatsAppConfiguration the default for instance). But also if they want to mix and match other configurations, they could simply define their own structs and impls on the CipherSuite trait.

That way, we also wouldn't have to feature-gate on the hash function, and we can essentially consolidate all of these configurations into one bundle-able trait.

Thoughts? ccing @slawlor and @dillonrg for feedback