[WIP] Add RsaPrivateKey/RsaPublicKey inherent methods

[tarcieri]

Adds algorithm-specific inherent methods for encryption and signing prefixed with the algorithm name, e.g. pkcs1v15_decrypt, pkcs1v15_sign, as an alternative to the PaddingScheme and SignatureScheme traits.

We already have an entirely separate trait-based API from PaddingScheme and SignatureScheme, namely traits like RandomizedEncryptor, RandomizedDecryptor, and Decryptor, along with the traits from the signature crate. These traits are well-typed and enforce usage of a particular algorithm's family of types, but also seem to have overlapping responsibilities / use cases to the PaddingScheme and SignatureScheme traits.

The current PaddingScheme and SignatureScheme traits do let you mix encryption and signing operations with a single key type (along with different algorithms), but they're a little awkward to use and I don't think we're getting a whole lot out of the trait-based abstraction they provide which isn't provided better by the aforementioned well-typed traits.

The goal of being able to execute any operation of any algorithm you want on a given key type can also be met by just having a bunch of methods which do exactly what you want, which is what this PR proposes.

[tarcieri]

Note: I only did pkcs1v15 for now to see if this is an acceptable way to go. Also missing tests.

I will say having two methods for when you do or don't have an RNG parameter is a lot easier than dealing with Option::<DummyRng>::None, and also means if getrandom is available we can opportunistically plug an RNG in.

[pinkforest]

opportunistically plug

Should it be a cfg() ?

This will also duplicate API surface and with #[inline] it will cause bigger code sizes - is the plan to remove the old API ?

Ideally it would be good to gate PSS/PKCS in/out too ?

[tarcieri]

Should it be a cfg() ?

It's the standard getrandom feature we have on pretty much every single @RustCrypto crate that uses an RNG.

is the plan to remove the old API ?

If we landed this I would suggest deprecating PaddingScheme and SignatureScheme but leaving them in-place for now and removing them in v0.11.

[pinkforest]

It's the standard getrandom feature w

Yea but it's always explicit API point where as this changes behaviour under the hood implicitly for anyone who hasn't asked for it (? especially in case any other crate includes the crate with the non-bifurcated feature.

would suggest deprecating

This will make prevent adopting trait based key data injection (if that were to be supported)

• trait ValidatedRsaPrivateComponents over struct RsaPrivateKey #640