API Gap: KeyPairGenerator

[dghgit]

There's currently nothing in traits.rs for this.

My learned machine colleague suggests a natural fit for the public/private key classes would be:

pub trait SignatureKeyPairGenerator<
    PK: SignaturePublicKey<PK_LEN>,
    SK: SignaturePrivateKey<SK_LEN>,
    const PK_LEN: usize,
    const SK_LEN: usize,
>
{
    /// Generates a key pair using the library's default OS-backed RNG.
    fn keygen() -> Result<(PK, SK), SignatureError>;

    /// Generates a key pair using the provided RNG.
    fn keygen_from_rng(rng: &mut dyn RNG) -> Result<(PK, SK), SignatureError>;
}

and

pub trait KEMKeyPairGenerator<
    PK: KEMPublicKey<PK_LEN>,
    SK: KEMPrivateKey<SK_LEN>,
    const PK_LEN: usize,
    const SK_LEN: usize,
>
{
    /// Generates a key pair using the library's default OS-backed RNG.
    fn keygen() -> Result<(PK, SK), KEMError>;

    /// Generates a key pair using the provided RNG.
    fn keygen_from_rng(rng: &mut dyn RNG) -> Result<(PK, SK), KEMError>;
}

These could then be combined with the appropriate types to simplify the notation for invoking one.

It's possible that KEMKeyPairGenerator might be better as EncryptionKeyPairGenerator in-case RSA/OAEP get's added at a later date, XDH might be another candidate for "Encryption" although again, it and Diffie-Hellman might deserve "Agreement".

[ounsworth]

I thought of doing this way back when I was building MLDSA and MLKEM, but I figured that the only reason that you'd need such a trait is if you need to be able to generate a keypair abstractly without knowing which algorithm you are generating a keypair for. I couldn't come up with an example of why you would need to do that (that isn't already handled more cleanly by the Factory crate).

Also, I think that an abstraction like this is going to make it hard for the library to detect if you are, for example, trying to invoke MLKEM with an X25519 key (or even MLKEM1024 with an MLKEM512 key) because you have now abstracted it to the point that all the compiler knows is that they are both KEMPrivateKeys and therefore you need a runtime check to catch the mismatch. The way it works today, key-alg mismatch is caught. So I think your learned machine colleague is suggesting something that'll end up being problematic.

(note: the factories should be able to handle this properly because even though the user doesn't know what algorithm is being abstracted under the factory, the factory enum does, so it should be able to prevent stuff like handing the wrong key to the wrong algorithm -- though this actually needs to be implemented as we don't currently have factories for Signature or KEM)

If you think it's important to have keygens standardized on a trait, then the other design option, of course, is to add the two keygen functions into the Signer / KEMDecapsulator / etc traits. Which I think would be cleaner.

[dghgit]

Not sure... for signature algorithms in particular you can push the abstraction a long way, at the moment how a key pair is generated seems to be up to the individual crate, having a general API might be the right answer. That said, I've realized it would be better to have a few of these (so SignatureKeyPairGenerator, KEMKeyPairGenerator, KTSKeyPairGenerator...) as you do need to know the class of the algorithm as part of this. I'd suggest we try workshoping it once a few more alternatives are available.