PALISADE Lattice Crypto Library
1.11.9
A lattice crypto library for software engineers by software engineers.
|
PRE algorithms implementation for BFVrns. More...
#include <bfvrns.h>
Public Member Functions | |
LPAlgorithmPREBFVrns () | |
LPEvalKey< Element > | ReKeyGen (const LPPublicKey< Element > newKey, const LPPrivateKey< Element > oldKey) const |
Ciphertext< Element > | ReEncrypt (const LPEvalKey< Element > ek, ConstCiphertext< Element > ciphertext, const LPPublicKey< Element > publicKey=nullptr) const |
template<> | |
LPEvalKey< DCRTPoly > | ReKeyGen (const LPPublicKey< DCRTPoly > newPK, const LPPrivateKey< DCRTPoly > origPrivateKey) const |
template<> | |
Ciphertext< DCRTPoly > | ReEncrypt (const LPEvalKey< DCRTPoly > ek, ConstCiphertext< DCRTPoly > ciphertext, const LPPublicKey< DCRTPoly > publicKey) const |
Public Member Functions inherited from lbcrypto::LPAlgorithmPREBFV< Element > | |
LPAlgorithmPREBFV () | |
LPEvalKey< Element > | ReKeyGen (const LPPrivateKey< Element > newKey, const LPPrivateKey< Element > origPrivateKey) const |
PRE algorithms implementation for BFVrns.
Element | a ring element. |
|
inline |
Default constructor
|
virtual |
This method implements re-encryption using the evaluation key generated by ReKeyGen.
The PRE scheme used can achieve two different levels of security, based on the value supplied in the publicKey argument:
If publicKey is nullptr, the PRE scheme is CPA-secure. If the publicKey of the recipient of the re-encrypted ciphertext is supplied, then the scheme is HRA- secure. Please refer to Cohen, "What about Bob? The inadequacy of CPA Security for proxy re-encryption", for more information on HRA security.
The tradeoff of going for HRA is twofold: (1) performance is a little worst because we add one additional encryption and homomorphic addition to the result, and (2) more noise is added to the result because of the additional operations - in particular, the extra encryption draws noise from a distribution whose standard deviation is scaled by K, the number of digits in the PRE decomposition.
ek | the evaluation key. |
ciphertext | the input ciphertext. |
publicKey | the public key of the recipient of the re-encrypted ciphertext. |
Reimplemented from lbcrypto::LPAlgorithmPREBFV< Element >.
|
virtual |
The generation of re-encryption keys is based on the BG-PRE scheme described in Polyakov, et. al., "Fast proxy re-encryption for publish/subscribe systems".
The above scheme was found to have a weakness in Cohen, "What about Bob? The inadequacy of CPA Security for proxy re-encryption". Section 5.1 shows an attack where given an original ciphertext c=(c0,c1) and a re-encrypted ciphertext c'=(c'0, c'1), the subscriber (Bob) can compute the secret key of the publisher (Alice).
We fix this vulnerability by making re-encryption keys be encryptions of the s*(2^{i*r}) terms, instead of simple addition as previously defined. This makes retrieving the secret key using the above attack as hard as breaking the RLWE assumption.
Our modification makes the scheme CPA-secure, but does not achieve HRA-security as it was defined in the Cohen paper above. Please look at the ReEncrypt method for an explanation of the two security definitions and how to achieve each in Palisade.
newKey | public key for the new private key. |
oldKey | original private key used for decryption. |
Reimplemented from lbcrypto::LPAlgorithmPREBFV< Element >.