crypto-common: `KeyInit` for public keys / separate keygen trait?

[tarcieri]

I was looking at replacing the ml_kem::EncodedSizeUser trait with KeySizeUser and KeyInit. This works fine for DecapsulationKey (i.e. private keys), but it's a little bit weird for EncapsulationKey since the KeyInit::generate_key* methods don't make sense for public keys.

I was wondering if perhaps they should be moved to their own separate keygen trait.

[newpavlov]

Yeah, KeyInit should not be used for public keys since it assumes that any randomly sampled key is a valid one. I am not sure that KeyInit is a great fit for private keys either. It may work fine for currently implemented KEMs since they use key as a seed, but in future we may have algorithms which are more similar to elliptic curves and reject some keys.

Maybe we should introduce separate traits for key pairs which would work with both ECC and KEMs? #1897 looks relevant as well.

[tarcieri]

Yeah, that sounds good. See e.g. https://docs.rs/ml-kem/latest/ml_kem/trait.KemCore.html#tymethod.generate

I can impl KeySizeUser on public keys still I guess, but it's missing a trait to do the encoding to an Array. I guess I can define one in kem for that for now.

[tarcieri]

It may work fine for currently implemented KEMs since they use key as a seed, but in future we may have algorithms which are more similar to elliptic curves and reject some keys.

I think there's pretty widespread agreement to use seeds going forward, and if the underlying algorithm needs to reject certain keys, it can use deterministic rejection sampling ala RFC6979

[tarcieri]

#2096 moves RNG to specific traits for interfacing with getrandom and rand_core, which would address this issue