|
Proxy Re-cryptography Library The core of the library is a C++ implementation of the proxy re-encryption schemes proposed by Giuseppe Ateniese, Kevin Fu, Matthew Green and Susan Hohenberger in NDSS 2005. The library is intended for use by C++ or C programs, though in principle it is possible to access library functions from higher-level languages such as Python or Perl. The long-term goal of this project is to collect a number of new proxy re-encryption and re-signature schemes into a single location so that researchers can evaluate their suitability for various applications. The current library implements two public-key proxy re-encryption schemes. In upcoming versions of this library we plan to implement additional primitives, including the proxy re-signature schemes of CCS '05, new proxy re-encryption schemes from TCC '06, and an Identity-Based re-encryption scheme from ACNS '07. Note: This library and the bibliography have not been actively maintained. If you're looking for a more up-to-date list of PRC-related papers, Jun Shao maintains an excellent bibliography here. This project is a part of the Advanced Crypto Software Collection.
Download The PRL is available under an academic software license. Click here to download the library.
Overview of Proxy Re-encryption Proxy re-encryption is a form of public-key encryption that allows a user Alice to "delegate" her decryption rights to another user Bob. Alternative solutions to this problem typically require Alice to divulge her secret key to Bob, or to enroll in some sort of key escrow system. This may be undesirable for a variety of reasons. In a proxy re-encryption scheme, Alice delegates a semi-trusted proxy to translate ciphertexts encrypted under her key into ciphertexts encrypted under Bob's key. Once delegated, the proxy operates independently of Alice. The proxy is considered "semi-trusted" because it does not see the content of the messages being translated, nor can it re-encrypt Alice's messages to users for whom Alice has not granted decryption rights. For example, if Alice and Bob are both users in an encrypted email system, Alice might wish to temporarily forward messages to Bob while she is away. In this setting, she might instruct the mail server (proxy) to automatically re-encrypt her incoming mail to Bob's key. Even if a malicious system administration wished to read Alice's mail, the message content would be unavailable to anyone besides Alice or Bob. When Alice returns, she can revoke Bob's decryption rights by instructing the proxy to cease re-encrypting messages to Bob. To delegate her decryption rights to Bob, Alice generates a "delegation key" (or "re-encryption key"), and sends this key to the proxy. The proxy uses this key to translate messages from Alice's key to Bob's key. The schemes implemented by the PRL are unidirectional. In a unidirectional scheme, delegations are "one-way", i.e., the proxy can re-encrypt Alice's messages to Bob, but cannot re-encrypt Bob's messages to anyone. Furthermore, Alice can generate a delegation key (to Bob) using only Bob's public key (and her secret key). It is not necessary that Bob be online or even know that delegation has taken place.
References Note: See Jun Shao's website for a more up-to-date bibliography!
"Improved Proxy Re-encryption Schemes with Applications to Secure Distributed Storage" (Conference version). G. Ateniese, K. Fu, M. Green, S. Hohenberger. Proceedings of the 12th Annual Network and Distributed Systems Security Symposium (NDSS 2005), San Diego, California, 2005. (Full Version PDF)
The PRL is Copyright (c) 2007, Matthew Green, Giuseppe Ateniese, Kevin Fu, Susan Hohenberger.
This material is based upon work supported by the National Science Foundation under Grant No. 0716142. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation. Web page design by Sam Small. |