Proxy re-encryption: Difference between revisions

Revision as of 20:49, 24 May 2005

Latest revision as of 16:54, 15 August 2025

(65 intermediate revisions by 53 users not shown)

Line 1:

'''Proxy re-encryption''' ('''PRE''') schemes are [[cryptosystems]] which allow third parties ([[proxy server|proxies]]) to alter a [[ciphertext]] which has been [[encryption|encrypted]] for one party, so that it may be decrypted by another.

{{cleanup}}

''This page could use some additional organization and links to source sites.''

==Examples of use==

'''Proxy re-encryption''' schemes are [[cryptosystem]]s which allow third-parties (proxies) to alter a [[ciphertext]] which has been encrypted for one party, so that it may be decrypted by another. For example, Bob could designate a proxy to re-encrypt message encrypted for him so that Charlie can decrypt them with his key. When Alice sends a message encrypted under Bob's key, the proxy alters the message and thus Charlie can decrypt it. This makes possible a number of applications, including email forwarding, law-enforcement monitoring, and content distribution.

A proxy re-encryption is generally used when one party, say Bob, wants to reveal the contents of messages sent to him and encrypted with his public key to a third party, Charlie, without revealing his private key to Charlie. Bob does not want the proxy to be able to read the contents of his messages.<ref>Nabeel's Blog, Seen Nov 2014, http://mohamednabeel.blogspot.ca/2011/03/proxy-re-encryption.html</ref>

'''ProxyBob re-encryption'''could schemesdesignate area [[cryptosystem]]sproxy whichto allow thirdre-partiesencrypt (proxies)one toof alterhis a [[ciphertext]] which has been encrypted for one party, somessages that itis mayto be decryptedsent byto anotherCharlie. ForThis example, Bob could designategenerates a proxynew to[[Key re-encrypt message encrypted for him so(cryptography)|key]] that Charlie can decryptuse themto withdecrypt histhe keymessage. WhenNow Aliceif Bob sends Charlie a message that was encrypted under Bob's key, the proxy alterswill alter the message, and thusallowing Charlie canto decrypt it. This makesmethod possibleallows for a number of applications, includingsuch emailas [[e-mail forwarding]], law-enforcement monitoring, and content distribution.

A weaker re-encryption scheme is one in which the proxy possesses both parties' keys simultaneously. One key decrypts a [[plaintext]], while the other encrypts it. Since the goal of many proxy re-encryption schemes is to avoid revealing either of the keys or the underlying plaintext to the proxy, this method is not ideal.

Proxy re-encryption schemes are similar to traditional [[symmetric cryptography|symmetric]] or [[asymmetric cryptography|asymmetric]] encryption schemes, with the addition of two functions. The first, ''delegation'', allows a message recipient (keyholder) to generate a ''re-encryption key'' based on his secret key and the key of the delegated user. This re-encryption key is used by the proxy as input to the ''re-encryption'' function, which is executed by the proxy to translate ciphertexts to the delegated user's key. Asymmetric proxy re-encryption schemes come in bi-directional and uni-directional varieties. In a ''bi-directional'' scheme, the re-encryption scheme is reversible-- that is, the re-encryption key can be used to translate messages from Bob to Charlie, as well as from Charlie to Bob. This can have various security consequences, depending on the application. One notable characteristic of bi-directional schemes is that both the delegator and delegated party (e.g., Charlie and Bob) must combine their secret keys to produce the re-encryption key. A ''uni-directional'' scheme is effectively one-way; messages can be re-encrypted from Bob to Charlie, but not the reverse. Uni-directional schemes can be constructed such that the delegated party need not reveal its secret key. For example, Bob could delegate to Charlie by combining his secret key with Bob's public key.

==Defining functions==

Another feature of proxy re-encryption schemes is ''transitivity''. ''Transitive'' proxy re-encryption schemes allow for a ciphertext to be re-encrypted an unlimited number of times. For example, a ciphertext might be re-encrypted from Bob to Charlie, and then again from Charlie to David and so on. ''Non-transitive'' schemes allow for only one (or a limited number) of re-encryptions on a given ciphertext. Currently, there is no known uni-directional, transitive proxy re-encryption scheme. It is an open problem as to whether such constructions are possible.

Proxy re-encryption schemes are similar to traditional [[Symmetric-key algorithm|symmetric]] or [[Public-key cryptography|asymmetric encryption]] schemes, with the addition of two functions:

* '''Delegation''' – allows a message recipient (keyholder) to generate a re-encryption key based on his secret key and the key of the delegated user. This re-encryption key is used by the proxy as input to the re-encryption function, which is executed by the proxy to translate ciphertexts to the delegated user's key. Asymmetric proxy re-encryption schemes come in bi-directional and uni-directional varieties.

** In a ''bi-directional scheme'', the re-encryption scheme is reversible—that is, the re-encryption key can be used to translate messages from Bob to Charlie, as well as from Charlie to Bob. This can have various security consequences, depending on the application. One notable characteristic of bi-directional schemes is that both the delegator and delegated party (e.g., Charlie and Bob) must combine their secret keys to produce the re-encryption key.

** A ''uni-directional scheme'' is effectively one-way; messages can be re-encrypted from Bob to Charlie, but not the reverse. Uni-directional schemes can be constructed such that the delegated party need not reveal its secret key. For example, Bob could delegate to Charlie by combining his secret key with Charlie's public key.

Another feature of proxy re-encryption schemes is* ''transitivity'Transitivity'''. – ''Transitive'' proxy re-encryption schemes allow for a ciphertext to be re-encrypted an unlimited number of times. For example, a ciphertext might be re-encrypted from Bob to Charlie, and then again from Charlie to David and so on. ''Non-transitive'' schemes allow for only one (or a limited number) of re-encryptions on a given ciphertext. Most known schemes are bi-directional and transitive. Currently, therethe is noonly known uni-directional, transitive proxy re-encryption scheme.is done Itthrough isthe anuse openof problem[[homomorphic asencryption]].<ref>{{Cite tobook|url=https://crypto.stanford.edu/craig/craig-thesis.pdf|title=A whetherFully suchHomomorphic constructionsEncryption areSystem|last=Gentry|first=Craig|date=September possible.2009|pages=35}}</ref>

* '''Cloud Computing''' – Proxy re-encryption has potential applications for secure sharing in a [[cloud computing]] environment. In the cloud scenario the re-encryption key is provided to the cloud operator/admin. Looking at the Bob, Charlie, David example, the cloud would take the place of Charlie. Bob generates a re-encryption key to supply to the cloud. The cloud operator/admin completes a re-encrypt of Bob’s encrypted files into David’s files whenever David downloads Bob’s files. Challenges exist with the cloud solution. A user could conspire with a cloud operator to gain access to all a user’s, such as Bob, files. A second potential challenge is segmentation via [[access control]]. A cloud user can restrict access to files via the assignment of conditional values. However, the number of re-encryption keys grows proportionately with the number of conditional values. This situation is not optimal for resource constrained devices.<ref>{{cite book |last1=W. Chen, C. Fan, Y. Tseng |title=2018 IEEE Conference on Dependable and Secure Computing (DSC) |chapter=Efficient Key-Aggregate Proxy Re-Encryption for Secure Data Sharing in Clouds |pages=1–4 |date=10–13 December 2018 |doi=10.1109/DESEC.2018.8625149|isbn=978-1-5386-5790-4 |s2cid=59232591 |chapter-url=http://etd.lib.nsysu.edu.tw/ETD-db/ETD-search/view_etd?URN=etd-0721117-175956 }}</ref>

Proxy re-encryption should not be confused with [[proxy signature]]s, which is a separate construction with a different purpose.

== See also ==

{{crypto-stub}}

* [[Identity-based conditional proxy re-encryption]]

==References==

[[Category:Cryptography]]

{{reflist}}

* M. Blaze, G. Bleumer, M. Strauss. [https://archive.today/20130212115133/http://link.springer.de/link/service/series/0558/bibs/1403/14030127.htm Divertible Protocols and Atomic Proxy Cryptography].

* Bertino, E., Sandhu, R. [http://ieeexplore.ieee.org/search/wrapper.jsp?arnumber=1416861 "Database security - concepts, approaches, and challenges."]{{dead link|date=January 2025|bot=medic}}{{cbignore|bot=medic}} ''IEEE Transactions on Dependable and Secure Computing'' 2 (2005): 2-19

* G. Ateniese, K. Fu, M. Green, S. Hohenberger. [http://spar.isi.jhu.edu/~mgreen/proxy.pdf Improved Proxy Re-encryption Schemes with Applications to Secure Distributed Storage]. Proceedings of the 12th Annual Network and Distributed Systems Security Symposium (NDSS 2005), San Diego, California, 2005.

* M. Green, G. Ateniese. [http://eprint.iacr.org/2006/473 Identity-Based Proxy Re-encryption]. Applied Cryptography and Network Security Conference, June 2007.

* S. Hohenberger, G. Rothblum, a. shelat, and V. Vaikuntanathan. Securely Obfuscating Re-encryption. Proceedings of the Theory of Cryptography Conference (TCC), 2007.

* [http://spar.isi.jhu.edu/~mgreen/prl/ The JHU-MIT Proxy Re-cryptography Library]

* [https://web.archive.org/web/20150916004239/http://ndc.zjgsu.edu.cn/~jshao/prcbib.htm Bibliography on Proxy Re-Cryptography]

[[Category:Public-key cryptography]]