Should `PaddingScheme` be a trait instead of an enum?

[tarcieri]

Looking at issues like #215 it seems like requirements of certain variants are making the others somewhat harder to use.

The PKCS1v15Encrypt and PKCS1v15Sign have relatively minimal requirements with PKCS1v15Encrypt having no members whatsoever, whereas OAEP and PSS both need Box<dyn DynDigest + Send + Sync>.

Having a trait would allow the impls to live in e.g. pkcs1v15 and pss modules as well, whereas right now the pkcs1v15 module only exposes encryption-related functionality.

[newpavlov]

Maybe it's better to completely remove PaddingScheme and instead introduce separate padding-specific methods on RsaPrivateKey?

[tarcieri]

@newpavlov both the public and private key need padding-related functionality. The public key needs to generate a padded message for encryption, and verify the padding with a signature, with the inverse true for private keys.

As it were the padding is already largely implemented as crate-private free functions. The real question is how to expose it in the public API.

[lumag]

I'd second @newpavlov here. I'd drop the PaddingScheme completely instead. For the sign/verify ops we have Signer / Verifer families which do not need PaddingScheme. So, I think, it would be logical to add Encryptor / Decryptor and drop the PS.

[tarcieri]

As I mentioned in #244, I'd like to get rid of the SignatureScheme trait I introduced there and move the relevant functionality to SigningKey and VerifyingKey.

I still think #244 is a reasonable first step towards splitting up the relevant functionality.

[lumag]

@tarcieri I'd start with something like #245

[tarcieri]

It's going to be a nightmare to rebase #244 on that 😢

It would've been better if you started with #244 as the base.

[lumag]

@tarcieri well, I branched off the trunk on purpose. IMHO there is no point in having SignatureScheme if we can drop it first.

[lumag]

@tarcieri @newpavlov @dignifiedquire Also I think that we should make encryption/decryption follow the Signer API. In other words, have a separate Encryptor / Decryptor traits, implement padding-specific keys and drop PaddingScheme completely.

[lumag]

I implemented my ideas as #246

[tarcieri]

Resolved by #244