Proxy re-encryption: Difference between revisions

Revision as of 07:19, 19 June 2006

Revision as of 00:22, 20 June 2006

Line 1:

{{sectionsExpert}}

{{technical}}

'''Proxy re-encryption''' 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.

'''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 messages 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. Clearly a naive proxy re-encryption scheme is possible if the proxy possesses both parties' keys, and simply decrypts with one to reveal a plaintext which is then encrypted with the other. However, the goal of many proxy re-encryption schemes is to avoid revealing either the keys, or the underlying plaintext to the proxy.

==Examples of Use==

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.

Bob could designate a proxy to re-encrypt one of his messages that is to be sent to Chris. This generates a new [[Key_(cryptography)|key]] that Chris can use to decrypt the message. Now if Alice sends Chris a message that was encrypted under Bob's key, the proxy will alter the message, allowing Chris to decrypt it. This method allows for a number of applications such as email 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 revelaing either of the keys or the underlying plaintext to the proxy, this method is not ideal.

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.

==Defining Functions==

Proxy re-encryption schemes are similar to traditional [[symmetric]] or [[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 Bob'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. 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 should not be confused with [[proxy signaturesignatures]]s, which is a separate construction with a different purpose.

==External Links==

*Bertino, E., Sandhu, R. [http://ieeexplore.ieee.org/search/wrapper.jsp?arnumber=1416861 "Database security - concepts, approaches, and challenges."] <u>IEEE Transations on Dependable and Secure Computing</u> 2 (2005): 2-19

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

== links ==

* [http://ieeexplore.ieee.org/search/wrapper.jsp?arnumber=1416861]

[[Category:Cryptography]]

{{crypto-stub}}