Free 30-min Web3 Consultation
Book Consultation
Smart Contract Security Audits
View Audit Services
Custom DeFi Protocol Development
Explore DeFi
Full-Stack Web3 dApp Development
View App Services
Free 30-min Web3 Consultation
Book Consultation
Smart Contract Security Audits
View Audit Services
Custom DeFi Protocol Development
Explore DeFi
Full-Stack Web3 dApp Development
View App Services
Free 30-min Web3 Consultation
Book Consultation
Smart Contract Security Audits
View Audit Services
Custom DeFi Protocol Development
Explore DeFi
Full-Stack Web3 dApp Development
View App Services
Free 30-min Web3 Consultation
Book Consultation
Smart Contract Security Audits
View Audit Services
Custom DeFi Protocol Development
Explore DeFi
Full-Stack Web3 dApp Development
View App Services
LABS
Glossary

Proxy Re-Encryption

Proxy Re-Encryption (PRE) is a cryptographic primitive that enables a semi-trusted proxy to transform a ciphertext encrypted for one party into a ciphertext decryptable by another, without the proxy learning the underlying plaintext.
Chainscore © 2026
definition
CRYPTOGRAPHY

What is Proxy Re-Encryption?

A cryptographic primitive that allows a semi-trusted proxy to transform a ciphertext encrypted for one party into a ciphertext that can be decrypted by another party, without the proxy learning the underlying plaintext or the secret decryption keys.

Proxy re-encryption (PRE) is a form of public-key cryptography where a proxy, given a special re-encryption key, can convert a ciphertext intended for Alice (the delegator) into a ciphertext that can be decrypted by Bob (the delegatee). Crucially, the proxy itself cannot decrypt the original or transformed messages, preserving confidentiality. This enables secure data sharing in encrypted storage systems, such as cloud services, without requiring data owners to be online to decrypt and re-encrypt files for each new recipient. The re-encryption key is generated by Alice using her private key and Bob's public key.

The core security property of PRE is that the proxy is semi-trusted or "honest-but-curious". It will correctly execute the re-encryption algorithm but is assumed not to collude with unauthorized parties. Schemes are categorized as unidirectional (Alice can delegate to Bob, but not vice-versa) or bidirectional, and as single-hop (a re-encrypted ciphertext cannot be re-encrypted again) or multi-hop. Most modern, practical implementations, like those based on pairing-based cryptography, are unidirectional and single-hop, offering a strong balance of security and efficiency for common data-sharing scenarios.

In blockchain and Web3, proxy re-encryption is a foundational technology for privacy-preserving data access. It enables use cases like secure key management for decentralized storage (e.g., allowing a user's private data on IPFS or Arweave to be shared via a proxy), confidential smart contract computations on encrypted inputs, and privacy-enhanced identity management. By separating the ability to transform data from the ability to decrypt it, PRE provides a powerful mechanism for implementing granular, cryptographically enforced access policies in distributed systems without a central trusted authority.

how-it-works
CRYPTOGRAPHIC PRIMITIVE

How Proxy Re-Encryption Works

A technical breakdown of the cryptographic mechanism that allows encrypted data to be securely transformed for a new recipient without exposing the underlying plaintext or the original decryption key.

Proxy re-encryption (PRE) is a cryptographic protocol that enables a semi-trusted proxy to transform a ciphertext encrypted for one user (the delegator) into a ciphertext that can be decrypted by a different user (the delegatee), without the proxy ever learning the plaintext data or the private keys of either party. This transformation is performed using a special re-encryption key generated by the delegator, which authorizes the proxy to perform this specific conversion. The core security property is that the proxy, while performing the computation, gains no ability to decrypt messages for either the original or the new recipient.

The process involves three core entities and follows a specific flow. First, the delegator (Alice) encrypts a message under her own public key and generates a re-encryption key from her private key to the public key of the delegatee (Bob). She sends this re-encryption key to the proxy. When the proxy receives a ciphertext intended for Alice, it applies the re-encryption key to transform it into a new ciphertext that is now encrypted for Bob. Finally, Bob can decrypt this transformed ciphertext using his own private key. This entire process occurs without the proxy or any other intermediary ever having access to the unencrypted message.

There are two primary types of proxy re-encryption schemes: unidirectional and bidirectional. In a unidirectional scheme, the re-encryption key only allows transformation from Alice to Bob, not vice-versa, offering greater control. A bidirectional scheme allows the proxy to re-encrypt ciphertexts in both directions. Most modern applications prefer unidirectional PRE for its enhanced security semantics. Schemes are also categorized by the number of hops (single-hop vs. multi-hop), determining if a re-encrypted ciphertext can be re-encrypted again by another proxy.

In blockchain and decentralized systems, PRE enables critical use cases like secure data sharing in decentralized storage (e.g., Filecoin, IPFS), where access permissions can be updated without re-uploading data, and confidential smart contracts that can process encrypted data. It also facilitates key management and recovery by allowing encrypted backups to be re-authorized for new devices. These properties make PRE a foundational technology for building privacy-preserving applications that require flexible and auditable access control over encrypted information.

key-features
MECHANICAL PROPERTIES

Key Features of Proxy Re-Encryption

Proxy Re-Encryption (PRE) is a cryptographic primitive that enables a semi-trusted proxy to transform ciphertext from one public key to another without accessing the underlying plaintext. Its key features define its security model and practical utility.

01

Unidirectional vs. Bidirectional

PRE schemes are classified by the direction of delegation. Unidirectional schemes allow a delegator to grant decryption rights to a delegatee, but not vice-versa, which is the most common and secure model. Bidirectional schemes allow mutual delegation, which is simpler but less secure for many applications. The choice depends on the trust model between parties.

02

Transitivity

This property determines if a re-encryption key can be chained. In a transitive scheme, if Alice delegates to Bob (via key rk_A→B) and Bob delegates to Carol (rk_B→C), then the proxy could theoretically re-encrypt from Alice to Carol. Non-transitive schemes prevent this chaining, offering finer-grained control and is generally preferred for enhanced security and auditability.

03

Key Privacy (Collusion Resistance)

A critical security property where the proxy and a malicious delegatee cannot collude to derive the private key of the original delegator. A collusion-resistant PRE scheme ensures that even if the proxy (holding re-encryption keys) and Bob (holding his private key) work together, they cannot compute Alice's private key. This is a non-negotiable requirement for most practical deployments.

04

Non-Interactivity

Defines how a re-encryption key is generated. In a non-interactive scheme, the delegator (Alice) can create the re-encryption key for the delegatee (Bob) using only Bob's public key and her own private key. Bob's participation is not required. This is a major usability advantage over interactive schemes, which require a protocol run between both parties.

05

CCA Security & Unlinkability

These are formal security definitions. CCA (Chosen-Ciphertext Attack) Security ensures the scheme is secure even when an adversary can obtain decryptions of other ciphertexts. Unlinkability means that given an original ciphertext and its re-encrypted version, the proxy (or an observer) cannot determine that they encrypt the same message, providing stronger privacy guarantees.

06

Use Case: Secure Data Sharing

A canonical example is cloud storage. Alice encrypts her files with her public key and uploads them. Later, she can generate a re-encryption key for Bob and give it to the cloud service (the proxy). The cloud can then transform her ciphertexts into ciphertexts Bob can decrypt with his key, without ever seeing the plaintext data. This enables efficient, access-controlled sharing without re-uploading data.

examples
PRACTICAL APPLICATIONS

Use Cases and Examples

Proxy Re-Encryption (PRE) enables secure, granular data sharing without exposing private keys. These examples illustrate its real-world utility in blockchain and beyond.

01

Secure Cloud Storage

A user encrypts a file with their public key and stores it on a cloud server. Using PRE, they can grant a colleague access by issuing a re-encryption key to the cloud provider. The provider transforms the ciphertext so only the colleague's private key can decrypt it, without ever seeing the original data or the user's private key.

02

Decentralized Data Marketplaces

PRE enables monetization of private data. A data owner can encrypt a dataset and list it for sale. A buyer purchases access, triggering the generation of a re-encryption key. The marketplace proxy (a smart contract or node) re-encrypts the data for the buyer's key, ensuring the seller's raw data and keys are never exposed to the marketplace operator.

03

Healthcare Record Sharing

A patient's medical records are encrypted under their public key. When referred to a specialist, the patient authorizes the hospital's proxy service to re-encrypt specific records for the specialist's public key. This allows compliant, auditable sharing under HIPAA-like regulations without centralized cleartext storage or master keys.

04

Cross-Chain & Cross-DApp Authorization

In DeFi, a user can authorize a service on Chain B to act on assets held in a vault on Chain A. A PRE scheme allows the generation of a re-encryption key that lets a relayer or oracle decrypt authorization messages on Chain A and re-encrypt them for Chain B, enabling secure cross-chain composability without private key movement.

05

Encrypted Messaging with Delegation

In an encrypted email or chat system, a user can delegate decryption rights to an assistant for a limited time or for specific message threads. The messaging server uses a re-encryption key to transform messages sent to the user so the assistant can read them, without the server learning the message content or the user's long-term private key.

06

Secure Audit & Compliance

A company encrypts its financial logs. For an annual audit, it issues a time-bound re-encryption key to an approved third-party auditor. The auditing firm can decrypt the logs for the compliance period without gaining permanent access or the company surrendering its master encryption key, satisfying regulatory requirements while minimizing exposure.

CRYPTOGRAPHIC PRIMITIVES

Comparison with Other Cryptographic Methods

How Proxy Re-Encryption (PRE) differs from related cryptographic techniques in terms of core functionality and data control.

Feature / PropertyProxy Re-Encryption (PRE)Public-Key Encryption (PKE)Attribute-Based Encryption (ABE)

Primary Function

Delegated ciphertext transformation between keys

Direct encryption/decryption for a single recipient

Encryption based on user attributes/policies

Data Re-Sharing Mechanism

Transformation by proxy without decryption

Requires decryption and re-encryption by data owner

Inherent in policy; access granted by attribute satisfaction

Data Owner Involvement for Sharing

One-time delegation (can be revoked)

Required for each new recipient

Defined once in the encryption policy

Proxy Capabilities

Semi-trusted; cannot decrypt plaintext

Not applicable

Not applicable

Granularity of Access Control

Per-delegation, recipient-specific

Per-keypair (user-specific)

Policy-based, can target groups

Computational Overhead

Moderate (re-encryption operation)

Low (standard encryption/decryption)

High (complex policy evaluation)

ecosystem-usage
APPLICATIONS

Ecosystem Usage

Proxy Re-Encryption (PRE) enables secure, granular data sharing without exposing private keys, unlocking new paradigms for decentralized applications.

03

Confidential Smart Contracts & DeFi

Enables private inputs for on-chain computations. Users can encrypt sensitive data (e.g., credit score, KYC status) and grant a smart contract temporary decryption rights via PRE to verify conditions without revealing the underlying data, enabling private credit scoring or confidential voting.

04

Healthcare & Secure Record Access

Facilitates HIPAA-compliant sharing of encrypted medical records. A patient's data remains encrypted at a hospital; using PRE, they can grant temporary access to a specialist or insurance provider without the hospital ever seeing the decryption key, ensuring patient privacy.

05

Cross-Chain & Interoperability Protocols

Secures the transfer of sensitive state or messages between blockchains. A relayer (proxy) can re-encrypt a proof or message intended for Chain A into a format readable by a smart contract on Chain B, enabling confidential cross-chain communication without exposing private validator keys.

06

Enterprise Data Collaboration

Allows companies to jointly analyze encrypted datasets for insights (e.g., fraud detection, supply chain optimization) without revealing proprietary information. PRE enables a trusted compute node to re-encrypt combined data for authorized analysts, preserving data sovereignty.

security-considerations
PROXY RE-ENCRYPTION

Security Considerations

Proxy Re-Encryption (PRE) enables secure data sharing by transforming encrypted data for authorized third parties without exposing the original decryption key. This section details the critical security models, assumptions, and potential vulnerabilities inherent to PRE systems.

01

Trust Model & Threat Assumptions

The security of a PRE system hinges on its defined trust model. Key questions include: Is the proxy semi-honest (follows protocol but curious) or malicious? Is the key generation authority trusted? Most schemes assume a semi-honest proxy that will not collude with unauthorized delegates. Understanding these assumptions is crucial for evaluating a PRE scheme's suitability for a given application, as a malicious proxy model requires more complex, often less efficient, cryptographic constructions.

02

Key Management & Revocation

A core challenge is managing the lifecycle of re-encryption keys. If a re-encryption key is compromised or needs to be revoked (e.g., an employee leaves), the data owner must:

  • Issue a new encryption key for future data.
  • Re-encrypt all existing ciphertexts under the new key.
  • Distribute new re-encryption keys to all still-authorized delegates. Without efficient revocation mechanisms, PRE systems can suffer from key escrow risks and bloated key states.
03

Collusion Resistance

A fundamental security property is collusion resistance: a proxy and a delegate should not be able to combine their knowledge to derive the data owner's private key. In a collusion attack, the proxy (holding the re-encryption key) and the delegate (holding their own private key) work together. Strong PRE schemes are designed so that such collusion reveals no information about the owner's secret key, preventing unauthorized access to all of the owner's data, not just the re-encrypted ciphertext.

04

Chosen-Ciphertext Attack (CCA) Security

For use in adversarial environments, PRE schemes must achieve Chosen-Ciphertext Attack (CCA) security. This means an adversary who can request decryptions or re-encryptions of chosen ciphertexts (except the target) cannot break the confidentiality of other messages. Many early PRE constructions were only secure against Chosen-Plaintext Attacks (CPA), which is insufficient if an attacker can influence the system's ciphertext processing. CCA-secure PRE is the modern standard.

05

Transparency & Auditability

In decentralized applications, it's critical to log and verify re-encryption events. Transparency ensures that data owners can audit:

  • When a re-encryption was performed.
  • For whom (which delegate's public key) it was performed.
  • By which proxy (or smart contract). Without verifiable logs on-chain or in a transparent ledger, malicious or erroneous re-encryptions cannot be detected, undermining accountability in the system.
06

Implementation Pitfalls

Theoretical security can be broken by implementation errors. Common pitfalls include:

  • Side-channel attacks on proxy servers during re-encryption computation.
  • Improve randomness for key generation, leading to predictable keys.
  • Logic flaws in access policy enforcement before triggering re-encryption.
  • Using PRE in inappropriate modes, like attempting to re-encrypt already re-encrypted data without proper scheme support. Rigorous code audits and formal verification are essential.
PROXY RE-ENCRYPTION

Common Misconceptions

Proxy Re-Encryption (PRE) is a powerful cryptographic primitive for secure data sharing, but its application in decentralized systems is often misunderstood. This section clarifies prevalent technical and conceptual errors.

No, Proxy Re-Encryption is a distinct cryptographic primitive that enables a transformation of ciphertexts, whereas end-to-end encryption (E2EE) is a communication model. In E2EE, data is encrypted by the sender and only decrypted by the intended recipient, with no intermediary access. Proxy Re-Encryption introduces a semi-trusted proxy that can transform a ciphertext encrypted for one party (the delegator) into a ciphertext that can be decrypted by another party (the delegatee), without the proxy ever learning the underlying plaintext or the decryption keys. This enables dynamic, policy-based sharing of encrypted data without requiring the original data owner to be online or re-encrypt the data themselves, a capability not present in standard E2EE.

PROXY RE-ENCRYPTION

Technical Details

A cryptographic primitive that enables secure data sharing without exposing the underlying encryption keys.

Proxy Re-Encryption (PRE) is a cryptographic scheme that allows a semi-trusted proxy to transform a ciphertext encrypted for one party into a ciphertext that can be decrypted by another party, without the proxy itself learning the plaintext or the secret keys. It enables secure, delegated data sharing in distributed systems like blockchain and cloud storage. The core innovation is that the data owner can grant access to a delegatee by issuing a re-encryption key to the proxy, which performs the transformation without ever having access to the unencrypted data. This is a key enabler for privacy-preserving applications where data sovereignty must be maintained.

PROXY RE-ENCRYPTION

Frequently Asked Questions

Proxy Re-Encryption (PRE) is a cryptographic primitive that enables secure data sharing without exposing private keys. This section answers common questions about its mechanics, use cases, and role in decentralized systems.

Proxy Re-Encryption (PRE) is a cryptographic protocol that allows a semi-trusted proxy to transform an encryption from one public key to another, without the proxy being able to decrypt the underlying data. In essence, it enables secure, delegated access to encrypted information. A data owner, Alice, can generate a special re-encryption key that authorizes the proxy to convert ciphertext intended for her into ciphertext that can be decrypted by another party, Bob. This process occurs without the proxy learning the plaintext or the private keys of either Alice or Bob, facilitating privacy-preserving data sharing in cloud storage, blockchain, and messaging systems.

evolution
CRYPTOGRAPHIC ORIGINS

Evolution and History

Proxy Re-Encryption (PRE) is a cryptographic primitive that allows a semi-trusted proxy to transform an encrypted message from one key to another without learning the underlying plaintext. Its development bridges the gap between secure data sharing and user privacy.

The concept of Proxy Re-Encryption was first formally introduced in a 1998 paper by Matt Blaze, Gerrit Bleumer, and Martin Strauss, who presented the idea of atomic proxy cryptography. This foundational work proposed a method where a trusted entity, the proxy, could convert a ciphertext encrypted for Alice into a ciphertext encrypted for Bob, using a special re-encryption key. Crucially, the proxy itself never gains access to the decryption keys or the plaintext data, establishing a core tenet of the technology. This solved a critical problem in key management and secure delegation long before the advent of modern decentralized systems.

Early PRE schemes were largely bidirectional, meaning the re-encryption key could transform ciphertexts in both directions between two users. A significant evolution came with the introduction of unidirectional PRE by Giuseppe Ateniese, Kevin Fu, Matthew Green, and Susan Hohenberger in 2005. Unidirectional schemes allow Alice to delegate decryption rights to Bob without Bob being able to reciprocate, which is essential for most practical applications like secure cloud storage or email forwarding. This period also saw the development of CCA-security (Chosen-Ciphertext Attack) models for PRE, significantly hardening the schemes against adversarial attacks and making them suitable for real-world deployment.

The rise of blockchain and decentralized systems catalyzed a new wave of innovation and application for PRE. Researchers and developers began exploring its use for private data sharing on public ledgers, confidential smart contracts, and decentralized access control. Modern implementations often leverage pairing-based cryptography on elliptic curves to construct efficient and secure PRE schemes. Projects now integrate PRE to enable functionalities like encrypting data to a blockchain address while allowing a designated proxy (often a smart contract or a network of nodes) to re-encrypt it for a data consumer, all without exposing sensitive information on-chain.

ENQUIRY

Get In Touch
today.

Our experts will offer a free quote and a 30min call to discuss your project.

NDA Protected
24h Response
Directly to Engineering Team
10+
Protocols Shipped
$20M+
TVL Overall
NDA Protected Directly to Engineering Team