Proxy Re-Encryption

The proxy can only transform ciphertexts from Alice to Bob, not the reverse. This is enforced cryptographically using a re-encryption key (RK) generated by Alice using her secret key and Bob's public key. The RK is mathematically directional—it contains the quotient of the two keys. This prevents the proxy from reversing the transformation or deriving either party's private key. Unidirectionality is critical for delegation scenarios where trust is asymmetric, such as granting read access to a subordinate without enabling them to re-share upward.

• Key generation: Alice computes RK_{A→B} using sk_A and pk_B
• Security guarantee: Proxy cannot compute RK_{B→A} from RK_{A→B}
• Use case: Hierarchical data sharing in enterprise file systems

Alice can generate the re-encryption key without any interaction with Bob. She only needs Bob's public key, which can be retrieved from a public key infrastructure (PKI) or directory. This non-interactive property is essential for asynchronous delegation—Alice can grant access to Bob even when Bob is offline or does not yet exist in the system. The scheme relies on the algebraic structure of pairing-based cryptography or lattice-based hardness assumptions to enable this offline delegation.

• No handshake required: Bob's participation is unnecessary during RK generation
• Enables pre-provisioning: Access can be granted before Bob joins the system
• Contrast with: Interactive proxy re-encryption schemes requiring Bob's secret key

Even if the proxy colludes with Bob and shares the re-encryption key, they cannot jointly recover Alice's secret key. This property, known as collusion safety or master secret security, is achieved through cryptographic separation: the re-encryption key encodes a transformation function, not a decryption capability. In pairing-based constructions, this relies on the hardness of the Bilinear Diffie-Hellman (BDH) problem. Without collusion resistance, a malicious proxy and delegatee could conspire to decrypt all of Alice's past and future ciphertexts.

• Threat model: Proxy + Delegatee coalition
• Protected secret: Alice's long-term private key sk_A
• Cryptographic basis: BDH assumption or LWE hardness in lattice-based variants

From Bob's perspective, a re-encrypted ciphertext is indistinguishable from a ciphertext originally encrypted under his public key. Bob uses his standard secret key sk_B for decryption—no special proxy-aware decryption algorithm is required. This transparency property means Bob's client software needs no modification to receive delegated data. The proxy transformation produces a valid second-level ciphertext that conforms exactly to the underlying encryption scheme's ciphertext space.

• Bob's decryption: Standard Decrypt(sk_B, C')
• No proxy metadata: Ciphertext format is identical to direct encryption
• Backward compatibility: Existing decryption clients work without upgrades

The proxy never learns the underlying plaintext during the transformation process. The re-encryption operation is performed entirely on ciphertexts—the proxy takes Enc(pk_A, m) and the re-encryption key RK_{A→B}, and outputs Enc(pk_B, m) without ever seeing m. This opacity is the defining characteristic that distinguishes a semi-trusted proxy from a fully trusted one. It enables architectures where cloud infrastructure or edge nodes can mediate secure data sharing without being granted decryption rights.

• Proxy's view: Only ciphertexts and re-encryption keys
• No decryption capability: Proxy lacks any secret key material
• Architectural implication: Enables secure cloud-based access control proxies

Single-hop PRE allows only one re-encryption: Alice → Proxy → Bob. The resulting ciphertext cannot be re-encrypted again. Multi-hop PRE enables transitive delegation chains: Alice → Proxy1 → Proxy2 → Carol, where each proxy applies its own re-encryption key. Multi-hop schemes require additional cryptographic machinery to prevent ciphertext bloat and manage noise accumulation. The choice between single-hop and multi-hop represents a trade-off between expressiveness and efficiency.

• Single-hop: Simpler construction, lower overhead, sufficient for most access control
• Multi-hop: Enables complex delegation graphs and cascading permissions
• Security consideration: Each hop introduces additional collusion risk vectors
• Lattice-based PRE: Often supports multi-hop natively via key switching techniques

The core cryptographic operation that enables proxy re-encryption. Key switching transforms a ciphertext encrypted under one secret key into a ciphertext encrypting the same plaintext under a different secret key.

• Requires a switching key generated by the original key holder
• Used extensively in homomorphic encryption for relinearization and rotation operations
• The proxy never learns either secret key during the transformation
• Forms the mathematical basis for both single-hop and multi-hop PRE schemes

An extension of standard PRE where the proxy can only transform ciphertexts that satisfy a specific condition embedded at encryption time.

• Conditions can be based on attributes, time windows, or keywords
• Enables fine-grained access control without trusting the proxy
• Used in attribute-based encryption systems for cloud data sharing
• Prevents unauthorized re-encryption even if the proxy is compromised
• Critical for regulatory compliance in healthcare and finance

The process by which a delegator creates a cryptographic token that authorizes the proxy to transform ciphertexts. This key is unidirectional or bidirectional depending on the scheme.

• Unidirectional: Alice can delegate to Bob, but Bob cannot delegate to Alice
• Bidirectional: The key works symmetrically between both parties
• Generated using the delegator's private key and delegatee's public key
• Can be time-limited or use-limited in advanced schemes
• Must be transmitted to the proxy over a secure channel

A cryptographic scheme where ciphertexts and secret keys are associated with attributes, and decryption succeeds only when attributes match a defined policy. PRE extends ABE for revocation and delegation.

• Ciphertext-Policy ABE: Access policy embedded in the ciphertext
• Key-Policy ABE: Access policy embedded in the user's key
• PRE enables dynamic re-encryption when user attributes change
• Eliminates the need to re-encrypt data from scratch during user revocation
• Foundational for secure cloud storage and digital rights management

Proxy re-encryption schemes constructed on lattice hardness assumptions like Learning With Errors (LWE), providing post-quantum security guarantees.

• Resistant to attacks by both classical and quantum computers
• Based on the same mathematical foundations as homomorphic encryption
• Supports key homomorphism for multi-hop re-encryption
• Enables PRE for FHE ciphertexts, allowing delegated computation on encrypted data
• Active area of NIST post-quantum standardization research