Recrypt

Private, shareable, revocable cloud storage

Recrypt is an open-source, quantum-resistant proxy recryption system for secure file sharing on untrusted storage. Files are encrypted end-to-end on your own device; a storage provider holds only ciphertext and can never read your data. You can grant another person or group access to a file, and later revoke that access — without ever exposing your private key or re-encrypting the file.

It is built on lattice-based cryptography (OpenFHE) with post-quantum signatures, and is approaching its 1.0 release. It is open source — the code is on GitHub.

The gap Recrypt fills

Decentralized systems have long been missing a component that centralized services take for granted: storage that is private, shareable, and revocable at the same time. A good storage provider should be highly available without acting as a trusted intermediary — it should never see the plaintext of what it stores, yet the owner should be able to delegate access to any other key and later withdraw it.

Today's dominant model gives that up entirely. Whoever runs the server can read everyone's data. That visibility is useful, and a number of companies have built large businesses on it, but it is neither secure nor private.

The personal data store (PDS) movement responded by pushing storage back to individuals. It is more decentralized, but asking non-technical people to run their own data pod has proven even harder than asking them to manage a private key — most people simply don't want to operate a storage server. The federated model is the common compromise: a set of providers run servers as a service, and users pick one. It lowers the blast radius — no single custodian holds everything — but it asks users to choose an operator with little reputation to go on. Operators are often hobbyists who move on, leaving users to migrate their data with no good rubric for where to go next.

Recrypt changes the board. You can store your data with any provider — even a fully centralized one — and the provider can never see it unencrypted. You can still share that data with any individual or group, and revoke their access later without worrying about leaked decryption keys. Privacy and sharing stop being mutually exclusive.

How it works

A proxy recryption (PRE) proxy transforms ciphertext encrypted for Alice into ciphertext for Bob without ever decrypting it. When Alice wants to share a file, she generates a recryption key and hands it to the proxy; the proxy can then re-target her ciphertext to Bob on demand. The proxy never sees plaintext, never holds anyone's secret key, and access is revoked by discarding the recryption key — no re-encryption required.

Recrypt uses a hybrid (KEM-DEM) design so this stays fast on real files:

• A fresh 256-bit symmetric key encrypts the file body with XChaCha20, with Blake3/Bao providing streaming integrity.
• That symmetric key is wrapped with the post-quantum PRE backend.
• On a share, only the wrapped key — on the order of a kilobyte — is recrypted. The file itself is never touched.

Files are stored content-addressed by their Blake3 hash on any S3-compatible backend, with a separate auth service controlling access by public key. Identities use dual signatures — classical ED25519 alongside post-quantum ML-DSA-87 — and the system ships with a command-line client (with an encrypted local wallet), an HTTP API, and generated Rust and TypeScript clients.

Trust model

Plaintext never leaves the client. The recryption proxy is semi-trusted: it holds the recryption keys and the metadata needed to do its job, so you rely on it to honor revocation — but it can never decrypt your data, and you can run it yourself.

Why lattices

The earliest PRE schemes relied on bilinear pairings, an extension of Diffie-Hellman techniques. Like much classical public-key cryptography, those constructions are vulnerable to attacks by a sufficiently capable quantum computer. Recrypt instead builds on lattice-based encryption, which is believed to be quantum-resistant.

This was made practical by OpenFHE — a high-quality, DARPA-funded open-source library for lattice-based and fully homomorphic cryptography. It handles the parts that make lattice work error-prone: parameter selection, noise management, and the underlying matrix operations. Recrypt's default PRE backend is OpenFHE's BFV scheme.

Prior art

Proxy re-encryption is well studied; what has been missing is a production-ready implementation aimed at this use case. In 2005, Ateniese, Fu, Green, and Hohenberger (AFGH) described the problem precisely:

A secure file system is a natural application of proxy re-encryption because the system often assumes a model of untrusted storage. [...] The server operators can distribute encrypted files without having access to the plaintext files themselves. [...] In contrast, our system makes use of a semi-trusted access control server. We propose a significant security improvement to the access control in cryptographic storage, using proxy cryptography to reduce the amount of trust in the access control server.

They even built unidirectional PRE into a secure distributed read-only file system (SFSRO) — but as an academic exercise rather than a deployed product. (At the bottom of the paper, the authors offer source-code access by email.)

More recently, NuCypher — now part of the Threshold Network — brought PRE to the public with its Umbral library, combining PRE with threshold cryptography. Umbral is solid, though Threshold's focus has moved toward cryptocurrency bridging rather than flexible storage access control. Duality has published strong work on homomorphic, lattice-based PRE, available in OpenFHE (blog, ePrint 2024/681), and there is ongoing academic work in the same direction (ePrint 2025/656). Recrypt's aim is to turn this body of theory into something people can actually run, leaning on tested libraries wherever possible.

What this enables

Centralized systems benefit from economies of scale and professional operation, but they see everything. Fully distributed systems keep data private but push hard operational and security burdens onto every user. The federated model sits in between, with the trust-in-operator problem described above.

Recryption removes the trade-off. You can keep all your data with a single provider for convenience, and even if that provider is breached your keys stay with you. You retain agility to move between providers, and you can adopt a federated arrangement — all without weakening security. The same primitive underwrites a range of applications:

• Secure cloud data sharing — the core case: upload data encrypted under your key, then grant and revoke fine-grained access through the proxy without the provider ever seeing plaintext.
• Encrypted email forwarding — the classic motivating example: a mail server holding a recryption key forwards encrypted mail re-targeted to the recipient, without the sender's secret key.
• Distributed and untrusted file systems — access control over encrypted files stored on servers that never learn the file keys.
• Healthcare data sharing — patients grant time-bound access to specific clinicians without revealing their main decryption key.
• Confidential data on public networks — store encrypted data off-chain and grant access via recryption keys, keeping shared data confidential on otherwise transparent systems.

Who's building it

Recrypt is developed under the IdentiKey project. Our founder worked at PGP in 2008 on its email encryption server, and saw firsthand both the political weight of public-key infrastructure and what genuine privacy affords people. The work since has centered on applied cryptography and decentralized systems built for non-experts to use on real problems. Fundamental technologies are rarely easy to apply, and usable software that enables a genuinely new capability is harder still — which is exactly the gap Recrypt is built to close.

We believe secure, private, revocable access control over cloud storage is a necessary building block for data sovereignty — and a meaningful step toward broader human sovereignty in the digital space.

Addendum

Open questions & directions

A few directions remain under active evaluation:

• Threshold proxies. Can the lattice-based approach be extended with threshold cryptography to split trust across multiple recryption proxies, as Umbral does for bilinear-pairing PRE?
• Storage substrate. The ideal pairing is a decentralized store with erasure coding for redundancy and privacy-preserving data validation.
• Federated discovery. Standardizing metadata querying — so a client can find a file's current storage location — would let users move freely between storage providers, or run their own.

A note on terminology

We use recryption (not "re-encryption") for the transformation of ciphertext from one key to another, recryption key for the key that enables it, and recrypted for data that has undergone it. The terminology is standardized throughout the codebase.