Is there a way of maintaining malleability in a homomorphic encryption system while making it infeasible to...











up vote
4
down vote

favorite
3













  • 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?










share|improve this question









New contributor




hdu is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
























    up vote
    4
    down vote

    favorite
    3













    • 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?










    share|improve this question









    New contributor




    hdu is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.






















      up vote
      4
      down vote

      favorite
      3









      up vote
      4
      down vote

      favorite
      3






      3






      • 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?










      share|improve this question









      New contributor




      hdu is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.












      • 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






      share|improve this question









      New contributor




      hdu is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.











      share|improve this question









      New contributor




      hdu is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      share|improve this question




      share|improve this question








      edited 2 days ago









      kelalaka

      3,3611929




      3,3611929






      New contributor




      hdu is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      asked 2 days ago









      hdu

      233




      233




      New contributor




      hdu is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.





      New contributor





      hdu is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.






      hdu is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.






















          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.






          share|improve this answer























            Your Answer





            StackExchange.ifUsing("editor", function () {
            return StackExchange.using("mathjaxEditing", function () {
            StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
            StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["$", "$"], ["\\(","\\)"]]);
            });
            });
            }, "mathjax-editing");

            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "281"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            convertImagesToLinks: false,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            noCode: true, onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });






            hdu is a new contributor. Be nice, and check out our Code of Conduct.










             

            draft saved


            draft discarded


















            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

























            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.






            share|improve this answer



























              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.






              share|improve this answer

























                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.






                share|improve this answer














                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.







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited 2 days ago

























                answered 2 days ago









                Mikero

                5,20711521




                5,20711521






















                    hdu is a new contributor. Be nice, and check out our Code of Conduct.










                     

                    draft saved


                    draft discarded


















                    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.















                     


                    draft saved


                    draft discarded














                    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





















































                    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







                    Popular posts from this blog

                    Quarter-circle Tiles

                    build a pushdown automaton that recognizes the reverse language of a given pushdown automaton?

                    Mont Emei