Prompted by https://github.com/RustCrypto/signatures/issues/25#issuecomment-525248346 and my desire to get #18 and #26 merged :smile:

The main design difference compared to the current traits is that instead of making the "padding scheme" a parameter of the pubkey sign/verify functions, we make each scheme a first-class primitive that wraps the common public or private key. It needs to be an explicit choice by the user anyway.

Current draft proposal (as of 2020-03-07) (without changes to the signature crate, and without handling the encryption cases):

// This module has been merged into master
mod raw {
    pub trait EncryptionPrimitive {
        /// Do NOT use directly! Only for implementors.
        fn raw_encryption_primitive(&self, plaintext: &[u8]) -> Result<Vec<u8>>;
    }

    pub trait DecryptionPrimitive {
        /// Do NOT use directly! Only for implementors.
        fn raw_decryption_primitive<R: Rng>(
            &self,
            rng: Option<&mut R>,
            ciphertext: &[u8],
        ) -> Result<Vec<u8>>;
    }
}

mod key {
    pub trait PublicKeyParts {
        /// Returns the modulus of the key.
        fn n(&self) -> &BigUint;
        /// Returns the public exponent of the key.
        fn e(&self) -> &BigUint;
        /// Returns the modulus size in bytes. Raw signatures and ciphertexts for
        /// or by this public key will have the same size.
        fn size(&self) -> usize {
            (self.n().bits() + 7) / 8
        }
    }

    pub trait PrivateKey: crate::raw::DecryptionPrimitive + PublicKeyParts {
        /// Could have functions like this for usability?
        pub fn sign_pkcs1v15(&self) -> crate::pkcs1v15::Signer;
        pub fn sign_pkcs1v15_blinded<R: Rng>(&self, rng: R) -> crate::pkcs1v15::Signer;
        pub fn sign_pss(&self) -> crate::pss::Signer;
        pub fn sign_pss_blinded(&self) -> crate::pss::Signer;
    }

    pub trait PublicKey: crate::raw::EncryptionPrimitive + PublicKeyParts {
        /// Could have functions like this for usability?
        pub fn verify_pkcs1v15(&self) -> crate::pkcs1v15::Verifier;
        pub fn verify_pss(&self) -> crate::pss::Verifier;
    }

    pub struct RSAPrivateKey { ... }

    impl crate::raw::DecryptionPrimitive for RSAPrivateKey { ... }

    impl PublicKeyParts for RSAPrivateKey { ... }

    impl PrivateKey for RSAPrivateKey {
        pub fn sign_pkcs1v15(&self) -> crate::pkcs1v15::Signer {
            crate::pkcs1v15::Signer::unblinded(self)
        }

        pub fn sign_pkcs1v15_blinded<R: Rng>(&self, rng: R) -> crate::pkcs1v15::Signer {
            crate::pkcs1v15::Signer::blinded(rng, self)
        }

        pub fn sign_pss(&self) -> crate::pss::Signer {
            crate::pss::Signer::unblinded(self)
        }

        pub fn sign_pss_blinded(&self) -> crate::pss::Signer {
            crate::pss::Signer::blinded(self)
        }
    }

    pub struct RSAPublicKey { ... }

    impl crate::raw::EncryptionPrimitive for RSAPublicKey { ... }

    impl PublicKeyParts for RSAPublicKey { ... }

    impl PublicKey for RSAPublicKey {
        pub fn verify_pkcs1v15(&self) -> crate::pkcs1v15::Verifier {
            crate::pkcs1v15::Verifier::new(self)
        }

        pub fn verify_pss(&self) -> crate::pss::Verifier {
            crate::pss::Verifier::new(self)
        }
    }
}

/// PKCS#1 v1.5 signing (and encryption?)
mod pkcs1v15 {
    use signature::Error;

    use crate::{
        key::{PrivateKey, PublicKey},
        raw::DecryptionPrimitive,
    };

    pub struct Signature {
        bytes: Vec<u8>,
    }

    impl signature::Signature for Signature {
        fn from_bytes(bytes: impl AsRef<[u8]>) -> Result<Self, Error> {
            // Parse a PKCS#1 v1.5 signature here non-contextually
            // (i.e. length can't be verified as we don't know n)
        }
    }

    // Technically all we need is K: DecryptionPrimitive, but PrivateKey
    // is the correct user-level encapsulation, and we should keep
    // DecryptionPrimitive internal as much as possible.
    pub struct Signer<'a, R: Rng, K: PrivateKey> {
        // RefCell in lieu of a stateful or randomizable signature trait
        rng: Option<RefCell<R>>,
        priv_key: &'a K,
    }

    impl<'a, R: Rng, K: PrivateKey> Signer<'a, R, K> {
        pub fn unblinded(priv_key: &'a K) -> Self {
            Signer { rng: None, priv_key }
        }

        pub fn blinded(rng: R, priv_key: &'a K) -> Self {
            Signer { rng: Some(RefCell::new(rng)), priv_key }
        }
    }

    impl<'a, R: Rng, K: PrivateKey> signature::Signer<Signature> for Signer<'a, R, K> {
        fn try_sign(&self, msg: &[u8]) -> Result<Signature, Error> {
            // Sign the message directly (equivalent to current None case)
        }
    }

    impl<'a, R: Rng, K: PrivateKey> signature::DigestSigner<D: Digest, Signature> for Signer<'a, R, K> {
        fn try_sign_digest(&self, digest: D) -> Result<Signature, Error> {
            // Sign the digest (equivalent to current Some(Hash) case)
        }
    }

    pub struct Verifier<'a, PK: PublicKey> {
        pub_key: &'a PK,
    }

    impl<'a, PK: PublicKey> Verifier<'a, PK> {
        pub fn new(pub_key: &'a PK) -> Self {
            Verifier { pub_key }
        }
    }

    impl<'a, PK: PublicKey> signature::Verifier<Signature> for Verifier<'a, PK> {
        fn verify(&self, msg: &[u8], signature: &Signature) -> Result<(), Error> {
            // Verify the message directly (equivalent to current None case)
        }
    }

    impl<'a, PK: PublicKey> signature::DigestVerifier<D: Digest, Signature> for Verifier<'a, PK> {
        fn verify_digest(&self, digest: D, signature: &Signature) -> Result<(), Error> {
            // Verify the digest (equivalent to current Some(Hash) case)
        }
    }
}

/// PSS signing
mod pss {
    use signature::Error;

    use crate::{
        key::{PrivateKey, PublicKey},
        raw::DecryptionPrimitive,
    };

    pub struct Signature {
        bytes: Vec<u8>,
    }

    impl signature::Signature for Signature {
        fn from_bytes(bytes: impl AsRef<[u8]>) -> Result<Self, Error> {
            // Parse a PSS signature here non-contextually
            // (i.e. length can't be verified as we don't know n)
        }
    }

    pub struct Signer<'a, R: Rng, K: PrivateKey> {
        // RefCell in lieu of a stateful or randomizable signature trait
        rng: RefCell<R>,
        priv_key: &'a K,
        salt_len: Option<usize>,
        blind: bool
    }

    impl<'a, R: Rng, K: PrivateKey> Signer<'a, R, K> {
        pub fn unblinded(rng: R, priv_key: &'a K, salt_len: Option<usize>) -> Self {
            Signer { rng: RefCell::new(rng), priv_key, salt_len, blind: false }
        }

        pub fn blinded(rng: R, priv_key: &'a K, salt_len: Option<usize>) -> Self {
            Signer { rng: RefCell::new(rng), priv_key, salt_len, blind: true }
        }
    }

    impl<'a, R: Rng, K: PrivateKey> signature::DigestSigner<D: Digest, Signature> for Signer<'a, R, K> {
        fn try_sign_digest(&self, digest: D) -> Result<Signature, Error> { ... }
    }

    pub struct Verifier<'a, PK: PublicKey> {
        pub_key: &'a PK,
    }

    impl<'a, PK: PublicKey> Verifier<'a, PK> {
        pub fn new(pub_key: &'a PK) -> Self {
            Verifier { pub_key }
        }
    }

    impl<'a, PK: PublicKey> signature::DigestVerifier<D: Digest, Signature> for Verifier<'a, PK> {
        fn verify_digest(&self, digest: D, signature: &Signature) -> Result<(), Error> { ... }
    }
}

// Do these improve usability?
pub use pkcs1v15::{
    Signature as Pkcs1v15Signature,
    Signer as Pkcs1v15Signer,
    Verifier as Pkcs1v15Verifier,
};
pub use pss::{
    Signature as PssSignature,
    Signer as PssSigner,
    Verifier as PssVerifier,
};

I'll update the proposal in this post as we discuss it.

Refactor the rsa crate to use the API defined by the signature crate. This adds pss and pkcs1v15 modules, each of them providing Signature, Verifier and Signer/RandomizedSigner implementations.

Blocked on https://github.com/dignifiedquire/num-bigint/pull/12

Missing: docs, tests and a way to avoid having base64 break our builds to rust-lang/cargo#4866.

Hi,

At first, thanks for this awesome library !

I'm trying to build rsa for the x86_64-unknown-uefi target, so in no_std environement.

After fixing the bug #138 by upgrading num-bigint-dig to 0.8.1 (btw you guys might want to fix that too). I'm getting an error from building getrandom (which is called from rand) as it doesn't support my target.

The fix is to enable the rdrand feature from getrandom.

I tried messing with rsa's Cargo.toml but I couldn't achieve to make it work.

I hoped you guys can help me.

EDIT: I just the saw the num-bigint-dig upgrade in a current PR

• [X] Change Signer/Verifier implementations to accept raw messages rather than pre-hashed data
• [X] Implement DigestSigner/Verifier traits
• [x] Get rid of DynDigest bounds for the RSASSA-PSS implmentation
• [x] Sort out specifying Hash to the pkcs1v15::SigningKey<D>::new_with_hash, which duplicates information passed in <D>
• [ ] ~~Use passed digest object for PSS calculations rather than newly created Digest?~~

Rework the crate to implement traits from the preview of the signature crate. Use Vec as Self::Repr type.

Note: I'm yet to see how will this impact the code in my projects. But for the evaluation I'd first need ecdsa / p384 to be updated.

cc @tarcieri @dignifiedquire

Generating a private key with more than 4096 bits using RsaPrivateKey::new and deriving a public key from it works fine, however when trying to read the same key from a string using RsaPublicKey::from_public_key_pem, the lib panics if the key uses more than 4096 bits, it works fine with 4096 or less, jumping to 4097 makes it panic.

Add OAEP encryption and decryption to RSA. Go's crypto module was a source of inspiration.

Since I am a Rustlang newbie, it probably cannot be merged as it is.

Here are important changes:

1. An oaep module has been added and made public (see 3 for the reason)
2. Hashes enum now has a digest function for most of enum's elements. Thus the import of sha-1,sha2 and sha3 crates
3. Keys now supports oaep encrypt/decrypt but only with default options (options cannot be changed) which are a sha1 digest and empty label
4. OAEP encode/decode options are the hash function (well Hashes instance) and a label. The hash function for the label and OAEP mask generation function cannot be chosen independently

Closes #75

Switches the rsa crate to use the pkcs1 and pkcs8 crates from https://github.com/rustcrypto/utils

Rationale

• Interoperability: PKCS#8 in particular is algorithm agnostic, and the pkcs8 crate provides the following traits which can be used to abstract over the algorithm used by a particular key (NOTE: this PR does not yet impl these traits, but probably should)
  • FromPrivateKey
  • FromPublicKey
  • ToPrivateKey
  • ToPublicKey
• Security: an upcoming ACM CCS paper claims to be able to extract RSA private keys from SGX using PEM parsing sidechannels alone. The new pem-rfc7468 crate implements a constant time PEM parser which leverages the base64ct crate for constant-time encoding/decoding.
• Parsimony: by switching to crates from https://github.com/rustcrypto/utils a user of the rsa crate who is also leveraging any of RustCrypto's elliptic curve crates such as p256, p384, or k256 will have fewer overall dependencies.
• PKCS#8 Encryption: the pkcs8 crate has support for ENCRYPTED PRIVATE KEYs using the pkcs5 crate. With this it can encrypt any PKCS#8 key under a password with scrypt-based key derivation and AES-CBC encryption (unfortunately PKCS#8 has no support for AEADs, alas)

Notes

This is the first time I've attempted to use the pkcs1 crate as it's brand new, so this integration is effectively taking it out for a test drive.

One of the key parts of format encoding/decoding with RSA when implementing PKCS#1 and PKCS#8 is that the latter is effectively a wrapper for the former in modern use. So therefore it seems like there should be a first-class integration between the pkcs1 and pkcs8 crates, namely I think the pkcs1 crate should support an optional dependency on pkcs8.

While the pkcs8 crate has some nice traits like the aforementioned FromPrivateKey/ToPrivateKey, the pkcs1 crate does not. The rsa crate defines some traits for this (e.g. PrivateKeyEncoding, PrivateKeyPemEncoding) but I really feel like the traits should get hoisted up into the pkcs1 crate.

If that were to happen, I think that the integration with the rsa crate could just be for PKCS#1 DER encoding/decoding. Concerns like PKCS#8 and PEM could be hoisted up into traits defined by the pkcs1 crate.

This pull request adds a new field to the OAEP padding to allow for a different hash function for the MGF mask function. This is especially needed, when trying to be compatible with other algorithms, more specifically the AndroidKeyStore. The AndroidKeyStore only supports RSA encryption with SHA256 and SHA1 for the MGF mask function.

For compatibility the existing functions were adjusted to replicate the previous behaviour to use the same hash function.

To the OAEP-Padding two new functions new_oaep_with_mgf_hash and new_oaep_with_mgf_hash_with_labe were added to allow specifying the MGF hash function.

as per the RFC 8017 [1], the NULL parameter MUST be present if the OID in AlgorithmIdentifier is rsaEncryption. this commit adds an explicit NULL to the AlgorithmIdentifier so that RSA keys encoded by this crate are compliant to the RFC:

The object identifier rsaEncryption identifies RSA public and private keys as defined in Appendices A.1.1 and A.1.2. The parameters field has associated with this OID in a value of type AlgorithmIdentifier SHALL have a value of type NULL.

[1] https://tools.ietf.org/html/rfc8017#appendix-A

fixes #91

The signing and verification is now implemented using the generic Signature and *Signer / *Verifier traits. Drop old API proprietary to the RSA crate.

Signed-off-by: Dmitry Baryshkov [email protected]

As proposed in #226, splits up the PaddingScheme enum into four structs, named after the previous variants of the struct (adopting capitalization from the Rust API guidelines):

• oaep::Oaep
• pkcs1v15::{Pkcs1v15Encrypt, Pkcs1v15Sign}
• pss::Pss

All of these are re-exported from the toplevel.

Each of these structs impls one or more of the following traits:

• PaddingScheme: used for encryption
• SignatureScheme: used for signing

The PaddingScheme constructors have been remapped as follows:

• new_oaep => Oaep::new
• new_oaep_with_label => Oaep::new_with_label
• new_oaep_with_mgf_hash => Oaep::new_with_mgf_hash
• new_oaep_with_mgf_hash_with_label => Oaep::new_with_mgf_hash_and_label
• new_pkcs1v15_encrypt => Pkcs1v15Encrypt
• new_pkcs1v15_sign => Pkcs1v15Sign::new
• new_pkcs1v15_sign_raw => Pkcs1v15Sign::new_raw
• new_pss => Pss::{new, new_blinded}
• new_pss_with_salt => Pss::{new_with_salt new_blinded_with_salt}

Hi, I have created an RSA key pair, and imported to openssl:

use openssl::pkey::PKey;
let pkey = PKey::private_key_from_der(private_key_der.as_bytes()).unwrap();
let mut signer = OpensslSigner::new(MessageDigest::sha256(), &pkey).unwrap();
signer.set_rsa_padding(openssl::rsa::Padding::PKCS1_PSS).unwrap();
signer.set_rsa_pss_saltlen(RsaPssSaltlen::custom(32)).unwrap();
signer.update(&data).unwrap();
let signature = signer.sign_to_vec().unwrap();

I can verify the signature with openssl:

use openssl::hash::MessageDigest;
use openssl::sign::{RsaPssSaltlen, Verifier};

let mut verifier = Verifier::new(MessageDigest::sha256(), &pkey).unwrap();
verifier.set_rsa_padding(openssl::rsa::Padding::PKCS1_PSS).unwrap();
verifier.set_rsa_pss_saltlen(RsaPssSaltlen::custom(32)).unwrap();
verifier.update(&message).unwrap();
verifier.verify(&signature)

But I can not verify the signature with rsa::pss and vice versa.

In #234 we had some people confused about signature verification failing with ::new, and they had trouble discovering ::new_with_prefix.

It would be good to either improve the documentation here, or eliminate the distinction between ::new and ::new_with_prefix and automatically determining if the prefix is needed (e.g. based on the OID of the provided digest).

It seems like other RSA libraries are able to make this determination automatically.

I am working on a project that has a policy to avoid BSD 2- and 3-clause licenses due to the complexity of satisfying the attribution clause:

Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

The rsa crate directly has great license options, but, it has a dependency on subtle which is licensed under BSD 3-clause license. See https://github.com/dalek-cryptography/subtle/issues/92. But it seems this project is stalled—see subtle-ng.

Is there any possibility of doing a substitution of this dependency with some other crate with different licensing? (subtle-ng also is BSD 3-clause licensed currently.)