- Rust 98.2%
- JavaScript 1.3%
- HTML 0.5%
| .github/workflows | updates CI to ignore non code changes | |
| benches | disallows unwrap() and adds anyhow crate | |
| examples | disallows unwrap() and adds anyhow crate | |
| src | upgrades x25519-dalek and ed25519-dalek | |
| web | removes explicit dependency on rand/rand_core | |
| .gitignore | gitignores Cargo.lock | |
| Cargo.toml | upgrades x25519-dalek and ed25519-dalek | |
| LICENSE | upgrades chacha20, bumps to v0.5.0, changes license | |
| README.md | upgrades chacha20poly1305 | |
| SECURITY.md | updates licensing | |
RGP
crates.io docs.rs dependency status License: AGPL v3
"Relatively Good Privacy"
Usage
usergp::{decrypt,encrypt,extract_components_mut,generate_dh_keys,generate_fingerprint,Components,Decrypt,Encrypt};fn main()-> anyhow::Result<()>{// generate sender fingerprint and public verifier
let(fingerprint,verifier)=generate_fingerprint();// generate key pairs for sender and recipient
let(sender_priv_key,sender_pub_key)=generate_dh_keys();let(recipient_priv_key,recipient_pub_key)=generate_dh_keys();letmutpub_keys=vec![recipient_pub_key];// 8mb
letcontent=vec![0u8;8_000_000];// add another 20,000 recipients
for_in0..20_000{let(_,pub_key)=generate_dh_keys();pub_keys.push(pub_key)}// encrypt message for all recipients
let(mutencrypted_content,content_key)=encrypt(fingerprint,content.clone(),Encrypt::Dh(sender_priv_key,&pub_keys,None),)?;// extract encrypted content key for first recipient
ifletComponents::Dh(encrypted_key,_)=extract_components_mut(0,&mutencrypted_content)?{// decrypt message
let(decrypted_content,decrypted_content_key)=decrypt(Some(&verifier),&encrypted_content,Decrypt::Dh(encrypted_key,sender_pub_key,recipient_priv_key,None,),)?;assert_eq!(decrypted_content,content);assert_eq!(decrypted_content_key,content_key);};Ok(())}More in the examples directory.
Disable Multi-threading
The "multi-thread" feature is enabled by default and utilizes the Rayon crate.
Multi-threading is currently only used in the encrypt function when using Dh or Kem modes to encrypt keys and
content in parallel, but can be disabled by setting default-features to false.
[dependencies]
rgp = { version = "x.x.x", default-features = false }
Modes
There are currently 4 supported top-level modes: Dh (Diffie-Hellman), Hmac, Session and Kem (Key Encapsulation
Mechanism). All modes embed content signing and verification; deniability is preserved by signing the plaintext and
encrypting the signature alongside the plaintext.
Ciphersuite
- Blake2s256 for HMAC
- Ed25519 for signatures
- mceliece348864f for KEM
- X25519 for Diffie-Hellman
XChaCha20for content keysXChaCha20Poly1305for content
Diffie-Hellman
Dh mode provides forward secrecy by generating a fresh/random content key for each message and encrypting a copy of
that key for each recipient with their respective shared secrets (similar to PGP session keys). This mode can be used to
manage the initial key exchange/ratchet seeding for Session and Hmac modes.
HMAC
Hmac mode provides backward secrecy, and can enable forward secrecy when the HMAC key is kept secret, if only the
content key is compromised. This mode also keeps track of an iterator to make ratcheting logic easier to implement.
Session
Session by default provides no forward or backward secrecy, and uses the provided key "as is" without any
modification. When used with keygen, Session can provide a forward secrecy for the content key as it will generate a
fresh/single-use content key that is itself encrypted with the session key, thus protecting the session key if only the
content key is compromised.
KEM
Kem mode is designed to facilitate public key cryptography for post-quantum encryption. It enables forward secrecy by
generating a fresh/random content key for each message and encrypting a copy of that key for each recipient with their
respective encapsulated keys.
This mode can be used to manage the initial key exchange/ratchet seeding for Session and Hmac as well as seed an
HMAC key for usage with Dh mode.
This mode depends on the classic-mceliece-rust crate. It is
recommended that the Kem with Diffie-Hellman hybrid, option be used until the underlying PQ crypto has been
sufficiently validated.
Classic McEliece was chosen despite its larger key sizes because it has a much smaller ciphertext, which is included
for each recipient on each message.
Performance
To check performance on your machine, run cargo bench. You can also view the latest benches in the GitHub
CI workflow.
All benchmarks for multi-recipient Dh and Kem mode are for 10,000 recipients, and all benchmarks for
sign+encrypt/decrypt+verify are using 5mb payloads.
Testing
The KEM library uses a large amount of memory, so cargo test needs to be run with the RUST_MIN_STACK set higher.
RUST_MIN_STACK=8388608 cargo test # optional: --no-default-features
License
Copyright 2026 Ordinary Labs, LLC
Licensed under the GNU AGPLv3: https://www.gnu.org/licenses/agpl-3.0.html
Security
THIS CODE HAS NOT BEEN AUDITED OR REVIEWED. USE AT YOUR OWN RISK.