Struct ring::signature::RSAKeyPair

pub struct RSAKeyPair { /* fields omitted */ }

An RSA key pair, used for signing. Feature: rsa_signing.

After constructing an RSAKeyPair, construct one or more RSASigningStates that reference the RSAKeyPair and use RSASigningState::sign() to generate signatures. See ring::signature's module-level documentation for an example.

Methods

impl RSAKeyPair

fn from_der(input: Input) -> Result<RSAKeyPair, Unspecified>

Parse a private key in DER-encoded ASN.1 RSAPrivateKey form (see RFC 3447 Appendix A.1.2).

Only two-prime keys (version 0) keys are supported. The public modulus (n) must be at least 2048 bits. Currently, the public modulus must be no larger than 4096 bits.

Here's one way to generate a key in the required format using OpenSSL:

openssl genpkey -algorithm RSA \
                -pkeyopt rsa_keygen_bits:2048 \
                -outform der \
                -out private_key.der

Often, keys generated for use in OpenSSL-based software are encoded in PEM format, which is not supported by ring. PEM-encoded keys that are in RSAPrivateKey format can be decoded into the using an OpenSSL command like this:

openssl rsa -in private_key.pem -outform DER -out private_key.der

If these commands don't work, it is likely that the private key is in a different format like PKCS#8, which isn't supported yet. An upcoming version of ring will likely replace the support for the RSAPrivateKey format with support for the PKCS#8 format.

The private key is validated according to NIST SP-800-56B rev. 1 section 6.4.1.4.3, crt_pkv (Intended Exponent-Creation Method Unknown), with the following exceptions:

• Section 6.4.1.2.1, Step 1: Neither a target security level nor an expected modulus length is provided as a parameter, so checks regarding these expectations are not done.
• Section 6.4.1.2.1, Step 3: Since neither the public key nor the expected modulus length is provided as a parameter, the consistency check between these values and the private key's value of n isn't done.
• Section 6.4.1.2.1, Step 5: No primality tests are done, both for performance reasons and to avoid any side channels that such tests would provide.

• Section 6.4.1.2.1, Step 6, and 6.4.1.4.3, Step 7:

  • ring has a slightly looser lower bound for the values of p and q than what the NIST document specifies. This looser lower bound matches what most other crypto libraries do. The check might be tightened to meet NIST's requirements in the future.

  • The validity of the mathematical relationship of dP, dQ, e and n is verified only during signing. Some size checks of d, dP and dQ are performed at construction, but some NIST checks are skipped because they would be expensive and/or they would leak information through side channels. If a preemptive check of the consistency of dP, dQ, e and n with each other is necessary, that can be done by signing any message with the key pair.

  • d is not fully validated, neither at construction nor during signing. This is OK as far as ring's usage of the key is concerned because ring never uses the value of d (ring always uses p, q, dP and dQ via the Chinese Remainder Theorem, instead). However, ring's checks would not be sufficient for validating a key pair for use by some other system; that other system must check the value of d itself if d is to be used.

In addition to the NIST requirements, ring requires that p > q and that e must be no more than 33 bits.

fn public_modulus_len(&self) -> usize

Returns the length in bytes of the key pair's public modulus.

A signature has the same length as the public modulus.

Trait Implementations

impl Sync for RSAKeyPair