OpenPGP implemented in pure Rust, permissively licensed
rPGP is a pure Rust implementation of OpenPGP as specified in RFC9580. It supports the commonly used v4 formats, as well as the latest v6 key formats and AEAD encryption mechanisms. (All formats specified in the historical RFCs RFC4880 and RFC6637, including v3 keys and signatures, are supported as well.)
See IMPL_STATUS
for more details on the implemented PGP features and "Overview of OpenPGP formats and mechanisms" for context about them.
rPGP offers a flexible low-level API. It gives users the ability to build higher level PGP tooling in the most compatible way possible. Additionally, it fully supports all functionality required by the Autocrypt 1.1 e-mail encryption specification.
- Delta Chat: Cross-platform messaging app that works over e-mail
debian-packaging
: A library crate for dealing with Debian packageshimalaya
: CLI to manage emails (includespgp-lib
component)oct-git
: Git signing and verification backend (with a focus on OpenPGP cards)prs-lib
: A CLI password manager inspired by pass (with optional rPGP backend, including OpenPGP card support)rpgpie
: An experimental OpenPGP semantics libraryrpm
: A pure rust library for parsing and creating RPM filesrsop
: A SOP CLI tool based on rPGP and rpgpiersop-oct
: A SOP CLI tool for OpenPGP card devices (also based on rPGP and rpgpie)signstar
: A signing enclave framework for HSM backendsvoa-openpgp
: OpenPGP implementation for VOA
Don't see your project here? Please send a PR :)
> cargo add pgp
use pgp::composed::{Deserializable, Message, SignedPublicKey};
fn main() -> pgp::errors::Result<()> {
let (public_key, _headers_public) = SignedPublicKey:: from_armor_file("key.asc")?;
let (mut msg, _headers_msg) = Message::from_armor_file("msg.asc")?;
if msg.verify(&public_key).is_ok() { // Verify using the primary (NOTE: This is not always the right key!)
// Signature is correct, print message payload
println!("Signed message: {:?}", msg.as_data_string()?);
}
Ok(())
}
use pgp::composed::{Deserializable, DetachedSignature, SignedPublicKey, SignedSecretKey};
use pgp::crypto::hash::HashAlgorithm;
use pgp::types::Password;
fn main() -> pgp::errors::Result<()> {
const DATA: &[u8] = b"Hello world!";
// Create a signature over DATA with the private key
let (private_key, _headers) = SignedSecretKey::from_armor_file("key.sec.asc")?;
let sig = DetachedSignature::sign_binary_data(
rand::thread_rng(),
&private_key.primary_key, // Sign with the primary (NOTE: This is not always the right key!)
&Password::empty(),
HashAlgorithm::Sha256,
DATA,
)?;
// Verify signature with the public key
let (public_key, _headers) = SignedPublicKey::from_armor_file("key.asc")?;
sig.verify(&public_key, DATA)?; // Verify with primary key (NOTE: This is not always the right key!)
Ok(())
}
bzip2
: Enables bzip2 supportasm
: Enables assembly based optimizationswasm
: Allows building for wasmmalformed-artifact-compat
: Be lenient towards some types of malformed artifacts (erroneously formed ECDH PKESK; invalidly short first partial body segments). Most users will NOT need this feature, should be disabled by default!draft-pqc
: Enables implementation of draft-ietf-openpgp-pqc-12 (This is unstable and can have breaking changes in patch releases. DO NOT USE IN PRODUCTION!)
Last updated September 2025
- Implementation Status:
IMPL_STATUS.md
- Security Status:
SECURITY_STATUS.md
- Supported Platforms:
PLATFORMS.md
See FAQ.md
.
rPGP aims to make it easy for application developers to incorporate OpenPGP functionality into their projects.
Note that the OpenPGP format and its semantics are relatively complex. We recommend the text "OpenPGP for application developers" for initial orientation.
Independently, we welcome questions in the rPGP issue tracker.
rPGP offers abstractions for handling the formats and mechanisms specified in RFC 9580. However, it offers them as relatively low-level building blocks, and doesn't attempt to ensure that users can not apply them unsafely.
rPGP allows following almost all parts of the OpenPGP specification, but the APIs are low level building blocks and do not claim that using them is (a) secure or (b) following the OpenPGP specification
Using the building blocks in rPGP correctly and safely requires a solid understanding of OpenPGP and at least a basic understanding of cryptography.
For context, OpenPGP can be thought of as a multi-layered technology, roughly like this:
- Wire format: Packet framing, Packet content, ASCII armor, ...
- Composite objects (e.g. Certificates, Messages) constructed according to grammars
- Functionality to process data, such as calculation and validation of OpenPGP signatures and encryption and decryption of messages.
- OpenPGP semantics (e.g.: Expiration and Revocation of Certificates and their components, Key Flags that define which semantical operations a given component key may be used for, signaling of algorithm preferences, ...)
Of these layers, the OpenPGP RFC specifies 1-3, while 4 is not specified in detail.
Some work on formalizing OpenPGP semantics can be found in draft-gallagher-openpgp-signatures and draft-dkg-openpgp-revocation.
Analogous to the RFC, rPGP handles layers 1-3, but explicitly does not deal with 4. Applications that need OpenPGP semantics must implement them manually, or rely on additional libraries to deal with that layer.
NOTE: The rpgpie
library implements some of these high level OpenPGP semantics.
It may be useful either to incorporate in rPGP projects, or to study for reference.
rPGP can handle a wide range of OpenPGP artifacts. It offers support for almost all mechanisms in OpenPGP, both modern and those now considered legacy.
This explicitly includes artifacts that use historical algorithms, which are considered insecure given today's understanding.
rPGP doesn't ensure that application developers use appropriate cryptographic building blocks for their purposes (even though it generally produces appropriately modern artifacts, by default).
See "Overview of OpenPGP formats and mechanisms" for more details on the evolution of OpenPGP over time.
All crates in this repository support Rust 1.85 or higher. In future minimally supported version of Rust can be changed, but it will be done with a minor version bump.
RFC 9580 support for rPGP has been funded in part through NGI0 Core, a fund established by NLnet with financial support from the European Commission's Next Generation Internet programme.
This project is licensed under either of
- Apache License, Version 2.0, (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
- MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)
at your option.
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in this project by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.