[WIP] Add RsaPrivateKey/RsaPublicKey inherent methods
#638
Conversation
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.
|
Note: I only did I will say having two methods for when you do or don't have an RNG parameter is a lot easier than dealing with |
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 ? |
It's the standard
If we landed this I would suggest deprecating |
Adds algorithm-specific inherent methods for encryption and signing prefixed with the algorithm name, e.g.
pkcs1v15_decrypt,pkcs1v15_sign, as an alternative to thePaddingSchemeandSignatureSchemetraits.We already have an entirely separate trait-based API from
PaddingSchemeandSignatureScheme, namely traits likeRandomizedEncryptor,RandomizedDecryptor, andDecryptor, along with the traits from thesignaturecrate. 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 thePaddingSchemeandSignatureSchemetraits.The current
PaddingSchemeandSignatureSchemetraits 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.