Is there a way of maintaining malleability in a homomorphic encryption system while making it infeasible to...
up vote
4
down vote
favorite
- Is there a way of maintaining malleability in a homomorphic encryption system while making it infeasible to perform chosen ciphertext attacks?
I have been reading about homomorphic encryption and malleable cryptosystems lately and have found it fascinating. I still have a lot of reading to do, however, I came across a statement in my reading that suggested malleability is inherently counter to security against chosen ciphertext attacks.
While I read up more about this relationship, I am curious to learn if there a way to maintain malleability while making a chosen ciphertext attack computationally infeasible? Why or why not?
homomorphic-encryption provable-security chosen-ciphertext-attack malleability
New contributor
add a comment |
up vote
4
down vote
favorite
- Is there a way of maintaining malleability in a homomorphic encryption system while making it infeasible to perform chosen ciphertext attacks?
I have been reading about homomorphic encryption and malleable cryptosystems lately and have found it fascinating. I still have a lot of reading to do, however, I came across a statement in my reading that suggested malleability is inherently counter to security against chosen ciphertext attacks.
While I read up more about this relationship, I am curious to learn if there a way to maintain malleability while making a chosen ciphertext attack computationally infeasible? Why or why not?
homomorphic-encryption provable-security chosen-ciphertext-attack malleability
New contributor
add a comment |
up vote
4
down vote
favorite
up vote
4
down vote
favorite
- Is there a way of maintaining malleability in a homomorphic encryption system while making it infeasible to perform chosen ciphertext attacks?
I have been reading about homomorphic encryption and malleable cryptosystems lately and have found it fascinating. I still have a lot of reading to do, however, I came across a statement in my reading that suggested malleability is inherently counter to security against chosen ciphertext attacks.
While I read up more about this relationship, I am curious to learn if there a way to maintain malleability while making a chosen ciphertext attack computationally infeasible? Why or why not?
homomorphic-encryption provable-security chosen-ciphertext-attack malleability
New contributor
- Is there a way of maintaining malleability in a homomorphic encryption system while making it infeasible to perform chosen ciphertext attacks?
I have been reading about homomorphic encryption and malleable cryptosystems lately and have found it fascinating. I still have a lot of reading to do, however, I came across a statement in my reading that suggested malleability is inherently counter to security against chosen ciphertext attacks.
While I read up more about this relationship, I am curious to learn if there a way to maintain malleability while making a chosen ciphertext attack computationally infeasible? Why or why not?
homomorphic-encryption provable-security chosen-ciphertext-attack malleability
homomorphic-encryption provable-security chosen-ciphertext-attack malleability
New contributor
New contributor
edited 2 days ago
kelalaka
3,3611929
3,3611929
New contributor
asked 2 days ago
hdu
233
233
New contributor
New contributor
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
8
down vote
accepted
I know of two lines of work on this question. It is indeed possible to allow malleability but still make some guarantees in the presence of a chosen-ciphertext attack:
Manoj Prabhakaran & Mike Rosulek: Reconciling Non-malleability with Homomorphic Encryption.
Dan Boneh and Gil Segev and Brent Waters: Targeted Malleability: Homomorphic Encryption for Restricted Computations.
Both papers present encryption schemes (and security definitions) that allow malleability $textsf{Enc}(m) leadsto textsf{Enc}(T(m))$ for some set of allowed transformations $T$ (as a feature), but where any other kind of malleability is infeasible.
As a concrete example, suppose the only allowable transformation is the identity transformation. Then it is possible to transform $textsf{Enc}(m)$ into another "fresh" encryption of the same (unknown) $m$. But it is infeasible to transform $textsf{Enc}(m)$ into any $m' ne m$ that is related to $m$. This special case is called "rerandomizable RCCA" encryption.
The first paper is my work, a combination of 3 of our conference papers; the one most relevant to your question is this one. Our construction has additional security requirement: a "transformed" ciphertext obtained via $textsf{Enc}(m) leadsto textsf{Enc}(T(m))$ should be indistinguishable from a "fresh" ciphertext (even to the private-key holder). We only consider the case of unary transformations, since n-ary transformations (i.e., combining several ciphertexts in a transformation) are impossible under these definitions.
The second paper does not have this extra requirement --- so "transformed" ciphertexts look different than "fresh" ciphertexts. They use an approach of appending a ZK proof that an allowable transformation was used on some original ciphertext.
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
8
down vote
accepted
I know of two lines of work on this question. It is indeed possible to allow malleability but still make some guarantees in the presence of a chosen-ciphertext attack:
Manoj Prabhakaran & Mike Rosulek: Reconciling Non-malleability with Homomorphic Encryption.
Dan Boneh and Gil Segev and Brent Waters: Targeted Malleability: Homomorphic Encryption for Restricted Computations.
Both papers present encryption schemes (and security definitions) that allow malleability $textsf{Enc}(m) leadsto textsf{Enc}(T(m))$ for some set of allowed transformations $T$ (as a feature), but where any other kind of malleability is infeasible.
As a concrete example, suppose the only allowable transformation is the identity transformation. Then it is possible to transform $textsf{Enc}(m)$ into another "fresh" encryption of the same (unknown) $m$. But it is infeasible to transform $textsf{Enc}(m)$ into any $m' ne m$ that is related to $m$. This special case is called "rerandomizable RCCA" encryption.
The first paper is my work, a combination of 3 of our conference papers; the one most relevant to your question is this one. Our construction has additional security requirement: a "transformed" ciphertext obtained via $textsf{Enc}(m) leadsto textsf{Enc}(T(m))$ should be indistinguishable from a "fresh" ciphertext (even to the private-key holder). We only consider the case of unary transformations, since n-ary transformations (i.e., combining several ciphertexts in a transformation) are impossible under these definitions.
The second paper does not have this extra requirement --- so "transformed" ciphertexts look different than "fresh" ciphertexts. They use an approach of appending a ZK proof that an allowable transformation was used on some original ciphertext.
add a comment |
up vote
8
down vote
accepted
I know of two lines of work on this question. It is indeed possible to allow malleability but still make some guarantees in the presence of a chosen-ciphertext attack:
Manoj Prabhakaran & Mike Rosulek: Reconciling Non-malleability with Homomorphic Encryption.
Dan Boneh and Gil Segev and Brent Waters: Targeted Malleability: Homomorphic Encryption for Restricted Computations.
Both papers present encryption schemes (and security definitions) that allow malleability $textsf{Enc}(m) leadsto textsf{Enc}(T(m))$ for some set of allowed transformations $T$ (as a feature), but where any other kind of malleability is infeasible.
As a concrete example, suppose the only allowable transformation is the identity transformation. Then it is possible to transform $textsf{Enc}(m)$ into another "fresh" encryption of the same (unknown) $m$. But it is infeasible to transform $textsf{Enc}(m)$ into any $m' ne m$ that is related to $m$. This special case is called "rerandomizable RCCA" encryption.
The first paper is my work, a combination of 3 of our conference papers; the one most relevant to your question is this one. Our construction has additional security requirement: a "transformed" ciphertext obtained via $textsf{Enc}(m) leadsto textsf{Enc}(T(m))$ should be indistinguishable from a "fresh" ciphertext (even to the private-key holder). We only consider the case of unary transformations, since n-ary transformations (i.e., combining several ciphertexts in a transformation) are impossible under these definitions.
The second paper does not have this extra requirement --- so "transformed" ciphertexts look different than "fresh" ciphertexts. They use an approach of appending a ZK proof that an allowable transformation was used on some original ciphertext.
add a comment |
up vote
8
down vote
accepted
up vote
8
down vote
accepted
I know of two lines of work on this question. It is indeed possible to allow malleability but still make some guarantees in the presence of a chosen-ciphertext attack:
Manoj Prabhakaran & Mike Rosulek: Reconciling Non-malleability with Homomorphic Encryption.
Dan Boneh and Gil Segev and Brent Waters: Targeted Malleability: Homomorphic Encryption for Restricted Computations.
Both papers present encryption schemes (and security definitions) that allow malleability $textsf{Enc}(m) leadsto textsf{Enc}(T(m))$ for some set of allowed transformations $T$ (as a feature), but where any other kind of malleability is infeasible.
As a concrete example, suppose the only allowable transformation is the identity transformation. Then it is possible to transform $textsf{Enc}(m)$ into another "fresh" encryption of the same (unknown) $m$. But it is infeasible to transform $textsf{Enc}(m)$ into any $m' ne m$ that is related to $m$. This special case is called "rerandomizable RCCA" encryption.
The first paper is my work, a combination of 3 of our conference papers; the one most relevant to your question is this one. Our construction has additional security requirement: a "transformed" ciphertext obtained via $textsf{Enc}(m) leadsto textsf{Enc}(T(m))$ should be indistinguishable from a "fresh" ciphertext (even to the private-key holder). We only consider the case of unary transformations, since n-ary transformations (i.e., combining several ciphertexts in a transformation) are impossible under these definitions.
The second paper does not have this extra requirement --- so "transformed" ciphertexts look different than "fresh" ciphertexts. They use an approach of appending a ZK proof that an allowable transformation was used on some original ciphertext.
I know of two lines of work on this question. It is indeed possible to allow malleability but still make some guarantees in the presence of a chosen-ciphertext attack:
Manoj Prabhakaran & Mike Rosulek: Reconciling Non-malleability with Homomorphic Encryption.
Dan Boneh and Gil Segev and Brent Waters: Targeted Malleability: Homomorphic Encryption for Restricted Computations.
Both papers present encryption schemes (and security definitions) that allow malleability $textsf{Enc}(m) leadsto textsf{Enc}(T(m))$ for some set of allowed transformations $T$ (as a feature), but where any other kind of malleability is infeasible.
As a concrete example, suppose the only allowable transformation is the identity transformation. Then it is possible to transform $textsf{Enc}(m)$ into another "fresh" encryption of the same (unknown) $m$. But it is infeasible to transform $textsf{Enc}(m)$ into any $m' ne m$ that is related to $m$. This special case is called "rerandomizable RCCA" encryption.
The first paper is my work, a combination of 3 of our conference papers; the one most relevant to your question is this one. Our construction has additional security requirement: a "transformed" ciphertext obtained via $textsf{Enc}(m) leadsto textsf{Enc}(T(m))$ should be indistinguishable from a "fresh" ciphertext (even to the private-key holder). We only consider the case of unary transformations, since n-ary transformations (i.e., combining several ciphertexts in a transformation) are impossible under these definitions.
The second paper does not have this extra requirement --- so "transformed" ciphertexts look different than "fresh" ciphertexts. They use an approach of appending a ZK proof that an allowable transformation was used on some original ciphertext.
edited 2 days ago
answered 2 days ago
Mikero
5,20711521
5,20711521
add a comment |
add a comment |
hdu is a new contributor. Be nice, and check out our Code of Conduct.
hdu is a new contributor. Be nice, and check out our Code of Conduct.
hdu is a new contributor. Be nice, and check out our Code of Conduct.
hdu is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f64335%2fis-there-a-way-of-maintaining-malleability-in-a-homomorphic-encryption-system-wh%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown