RustCrypto's RSA crate implements four RFC 8017 schemes, with one open advisory

Four schemes, all defined by RFC 8017

The rsa crate is a portable RSA implementation in pure Rust, and its scheme coverage is stated in a table rather than left to inference. Two encryption schemes are provided: RSAES-OAEP and RSAES-PKCS1-v1_5, specified in RFC 8017 sections 7.1 and 7.2. Two signature schemes are provided: RSASSA-PSS and RSASSA-PKCS1-v1_5, from sections 8.1 and 8.2 of the same document. That is the complete set of padding and scheme options the crate documents, and it maps directly onto what a protocol integrating with existing infrastructure is likely to need. The crate name on crates.io is `rsa`, it is published from the RustCrypto organisation, and the implementation carries no C or OpenSSL dependency, so it can be built for targets where those are not available. The trade-off implied by that choice is the one described below: a self contained implementation that is not yet where the RustCrypto project wants it to be.

PKCS#1 v1.5 encryption is explicitly a compatibility path

The documentation is unusually direct about which padding you should use. It states that PKCS#1 v1.5 encryption is provided for compatibility with legacy applications only, and that OAEP and PSS should be preferred for new encryption applications. That guidance matters more than the API surface, because choosing the crate without reading it is how a v1.5 encrypted channel ends up in a new deployment. The status checklist in the repository records the same asymmetry from the other side: PKCS#1 v1.5 encryption and decryption, signing and verification, OAEP encryption and decryption, PSS sign and verify, prime generation, key generation and key import and export are all marked done, while one line, PKCS#1 v1.5 session key encryption and decryption, is not. In other words, the legacy path is the least finished part of the legacy path, which is a reasonable place to draw a line for interoperability with older peers.

The example shows OAEP with Sha256 and blinded decryption

The README's example is short enough to read in full and shows the shape of the API. A private key is generated with `RsaPrivateKey::new` at a given bit length, a public key is derived from it, and the message is encrypted with `pub_key.encrypt` using `Oaep::<Sha256>::new()` and decrypted with `priv_key.decrypt_blinded` using the same padding:

use rsa::{Oaep, RsaPrivateKey, RsaPublicKey};
use sha2::Sha256;

let mut rng = rand::rng();
let bits = 2048;
let priv_key = RsaPrivateKey::new(&mut rng, bits).expect("failed to generate a key");
let pub_key = RsaPublicKey::from(&priv_key);

The naming of the decrypt method is the interesting part. `decrypt_blinded` performs blinding, which is the technique the security section describes as masking the timing variability of a modular exponentiation that is not constant time. The example also notes a practical wrinkle: if key generation seems unusually slow, compiling in release mode helps, and adding a debug profile with `opt-level = 3` to your Cargo.toml does the same at the cost of a longer compile.

The crate is affected by the Marvin Attack advisory

The security section is the part of this repository you should read before anything else. It records that the crate has received one security audit by Include Security, with one minor finding which has since been addressed. It then states that the implementation of modular exponentiation is not constant time, that timing variability is masked using random blinding, and, in the same paragraph, that the crate is vulnerable to the Marvin Attack, which could enable private key recovery by a network attacker, tracked as RUSTSEC-2023-0071. The mitigation work is tracked in issue 390, and the project points readers to its open security issues for other known problems. A side channel that can recover a private key from a network position is a different class of problem from a padding oracle or a parsing bug, and the repository itself does not present it as a minor issue.

Three phases, and the security phase is untouched

The status section describes a deliberate path to a 1.0 release, split into three phases with the current position stated up front. The first phase, make it work, is where the crate sits now, and its checklist is mostly complete apart from the v1.5 session key item. The second phase, make it fast, has benchmarks marked done, while comparing to other implementations and optimisation are both still open. The third phase, make it secure, is where both fuzz testing and security audits remain unchecked. That ordering is informative on its own: the project treats constant time implementation and adversarial review as a distinct, later stage of the work, and it publishes that plan rather than presenting the crate as finished. Anyone reading a dependency list that names the `rsa` crate should note that the pre-1.0 version line, and the checklist above, are part of what they are adopting.

Cargo.toml shows a small dependency set and optional format crates

The manifest tells you what the crate pulls in and what you can leave out. The package metadata gives the version as 0.10.0-rc.19, the edition as 2021 and the minimum supported Rust version as 1.85. The required dependencies are const-oid, crypto-bigint, crypto-primes, digest, rand_core, signature and zeroize, and everything else is optional:

[dependencies]
const-oid = { version = "0.10", default-features = false }
crypto-bigint = { version = "0.7", default-features = false, features = ["zeroize", "alloc"] }
crypto-primes = { version = "0.7", default-features = false }

The optional entries are where the format and algorithm choices live: pkcs1 and pkcs8 for the key encodings, spki for public key formats, sha1 and sha2 for the hash functions used in OAEP and PSS, serde with derive for serialisation, serdect for a serde-based encoding format, and crypto-common with the getrandom feature. The repository also carries benches, tests, a marvin-toolkit directory and a thirdparty directory, plus CHANGELOG.md, SECURITY.md and release.toml for the release process.

Dual licensing, a 1.85 floor and no tagged releases

The crate is licensed under either the Apache License, Version 2.0 or the MIT licence, at your option, and contributions are dual licensed the same way unless the author states otherwise. That is a permissive position with no obligation to publish changes. The minimum supported Rust version is 1.85 or higher, and the documentation notes that MSRV can be changed in the future, but only with a minor version bump, which is a useful commitment for downstream projects that pin a toolchain. The repository has no GitHub releases, so versions are cut from the manifest rather than from tagged artefacts, and the last push to the repository was on 2026-10-19. The repository is not archived. For a library that other people's security depends on, the combination of an unreleased 1.0, a published advisory and an open security checklist is the practical state of the project, whatever the version number suggests.

Editorial conclusion

Engineers who need RSA interoperability with existing systems, want a pure Rust dependency tree and can track a release candidate will find this crate worth reading, since the scheme coverage matches RFC 8017 closely and the API is small. It is the wrong choice for new designs, where the project's own guidance points to OAEP and PSS over the v1.5 padding, and it is the wrong choice for long-lived private keys while RUSTSEC-2023-0071 stands. Before adopting it, read the open security issues for the crate and check the mitigation work tracked in issue 390, then decide whether the RSA scheme itself is what your protocol actually requires.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. RustCrypto/RSA on GitHub