Sharing encrypted data is harder than encrypting it. If a file is encrypted under Alice's public key, only Alice's private key can decrypt it. The obvious way to share it with Bob is for Alice to download the file, decrypt it, re-encrypt it under Bob's key, and upload it again. That works, but it forces Alice to be online and to do the work, and — more importantly — if you wanted the server to handle the forwarding, the naive approach requires the server to decrypt, which means handing the server the plaintext. That defeats the entire point of encrypting in the first place.
Proxy re-encryption (PRE) solves this with a genuinely surprising capability: a semi-trusted intermediary — the proxy — can transform a ciphertext encrypted for Alice into a ciphertext encrypted for Bob, without learning the underlying message and without holding either party's private key. The primitive was introduced by Blaze, Bleumer, and Strauss in 1998, and substantially improved by Ateniese, Fu, Green, and Hohenberger in the mid-2000s.
The Re-Encryption Key
The magic ingredient is a special object called a re-encryption key, usually written rkA→B. Alice generates it using her own private key and Bob's public key. Crucially, this re-encryption key is not a decryption key — by itself it cannot recover any message. It is a one-directional transformation token: "convert things addressed to Alice into things addressed to Bob."
Alice hands rkA→B to the proxy. From then on, when a ciphertext encrypted under Alice's public key arrives, the proxy applies the re-encryption key and produces a new ciphertext that Bob can decrypt with his own private key. The proxy performs the transformation mechanically. It sees ciphertext go in and different ciphertext come out, and at no point does it see the message or possess the power to decrypt anything on its own behalf.
A re-encryption key is a delegation token, not a decryption key. It encodes only the relationship "re-address Alice's mail to Bob." Held alone, it unlocks nothing — which is exactly why it's safe to give to a server you don't fully trust.
What the Proxy Can and Cannot Do
Pinning down the trust boundary is the whole point of the scheme. The proxy is "semi-trusted": you rely on it to perform the transformation and to be available, but you do not rely on it to keep your data confidential, because it structurally cannot read it. Specifically:
- It cannot read the plaintext. Re-encrypting is not decrypting; the message stays opaque end to end.
- It cannot recover Alice's private key from the re-encryption key — in a secure scheme, rkA→B leaks nothing about Alice's secret.
- It cannot invent new delegations. It can only transform along the exact A→B direction Alice authorized.
What it can do is refuse to perform the transformation — it is still a point of availability, not confidentiality. And the access-control decision is real: once Alice issues rkA→B, the proxy can re-encrypt every Alice-ciphertext it sees to Bob, so PRE delegates access at the granularity the scheme supports rather than per-message unless you design for that.
The Properties That Distinguish Schemes
Not all proxy re-encryption is the same, and the differences matter for security:
| Property | What it means |
|---|---|
| Unidirectional | rkA→B transforms only A→B, not B→A. Bidirectional schemes convert both ways from one key — convenient, but a broader grant of trust. |
| Single-hop vs multi-hop | Single-hop allows one transformation (A→B). Multi-hop allows chaining (A→B→C), which is powerful but expands the attack surface. |
| Collusion resistance | If the proxy and Bob collude, can they recover Alice's private key? A collusion-resistant scheme says no — they learn nothing beyond what Bob could already decrypt. |
| Non-transitive | The proxy cannot combine rkA→B and rkB→C to forge rkA→C on its own. |
Collusion resistance is the one to watch. In some early bidirectional schemes, a proxy that teamed up with the delegatee could reconstruct the delegator's secret key. The unidirectional, collusion-resistant constructions that followed are what make PRE safe to deploy against a genuinely untrusted server.
Where It Gets Used
Proxy re-encryption is a natural fit anywhere encrypted data needs to be shared or forwarded through infrastructure you don't fully trust:
- Encrypted email forwarding. A mail server can forward an encrypted message to a new recipient without the server ever decrypting it.
- Encrypted cloud storage sharing. Grant a colleague access to an encrypted file by issuing a re-encryption key to the storage provider, instead of downloading, decrypting, and re-uploading yourself.
- Key rotation. Re-encrypt a large body of stored ciphertext to a new key without exposing the plaintext during the migration.
- Decentralized access control. Several decentralized storage and data-sharing networks use threshold variants of PRE — splitting the re-encryption capability across multiple proxies so no single one can act alone — to manage who can decrypt what.
It composes naturally with the goals of end-to-end encrypted cloud storage, where the entire premise is that the provider stores data it cannot read.
The Honest Caveats
Proxy re-encryption is elegant, but it is not free of trust assumptions, and it is worth being clear-eyed about them. The proxy is still trusted for availability and to actually apply the correct transformation; a malicious proxy can deny service or misbehave even if it cannot read your data. Granting a re-encryption key is a coarser act than approving a single message — in basic schemes it authorizes re-encryption of everything addressed to you, so conditional and time-bounded variants exist precisely to narrow that grant. And like all more advanced primitives, PRE adds cryptographic complexity and is less battle-tested in deployment than plain public-key encryption, which is its own kind of risk.
Proxy re-encryption does not remove trust from the system. It relocates it — from "the server can read my data" to "the server can transform but never read my data." That relocation is the entire value, and naming it precisely is the difference between a real guarantee and a marketing claim.
Why It's Worth Understanding
PRE belongs to a family of "encrypted computation" primitives — alongside homomorphic encryption and secure multiparty computation — that share a single radical ambition: let untrusted infrastructure do useful work on data it cannot see. Each makes a different, carefully bounded trade. PRE's particular trade is delegation: it lets you hand off the right to re-route encrypted access without ever handing off the right to read.
That instinct — push capability to the server while keeping the power to read strictly on the user's device — is the same one that guides Haven's architecture. Your encryption keys are derived on your device and never leave it; the servers move and store ciphertext they cannot open. Proxy re-encryption is a vivid example of just how far that principle can be pushed when the cryptography is designed for it.