Corrigendum: Public‐key encryption indistinguishable under plaintext‐checkable attacks

IET Information SecurityVolume 14, Issue 3 p. 365-366 CorrigendumFree Access Corrigendum: Public-key encryption indistinguishable under plaintext-checkable attacks This article corrects the following: Public-key encryption indistinguishable under plaintext-checkable attacks Michel Abdalla, Fabrice Benhamouda, David Pointcheval, Volume 10Issue 6IET Information Security pages: 288-303 First Published online: November 1, 2016 Michel Abdalla, Corresponding Author Michel Abdalla michel.abdalla@ens.fr DIENS, Ecole normale supérieure, CNRS, PSL University, Paris, France INRIASearch for more papers by this authorFabrice Benhamouda, Fabrice Benhamouda orcid.org/0000-0002-8300-1820 IBM Research, Yorktown Heights, NY, USASearch for more papers by this authorDavid Pointcheval, David Pointcheval DIENS, Ecole normale supérieure, CNRS, PSL University, Paris, France INRIASearch for more papers by this author Michel Abdalla, Corresponding Author Michel Abdalla michel.abdalla@ens.fr DIENS, Ecole normale supérieure, CNRS, PSL University, Paris, France INRIASearch for more papers by this authorFabrice Benhamouda, Fabrice Benhamouda orcid.org/0000-0002-8300-1820 IBM Research, Yorktown Heights, NY, USASearch for more papers by this authorDavid Pointcheval, David Pointcheval DIENS, Ecole normale supérieure, CNRS, PSL University, Paris, France INRIASearch for more papers by this author First published: 01 May 2020 https://doi.org/10.1049/iet-ifs.2019.0200AboutSectionsPDF ToolsRequest permissionExport citationAdd to favoritesTrack citation ShareShare Give accessShare full text accessShare full-text accessPlease review our Terms and Conditions of Use and check box below to share full-text version of article.I have read and accept the Wiley Online Library Terms and Conditions of UseShareable LinkUse the link below to share a full-text version of this article with your friends and colleagues. Learn more.Copy URL Share a linkShare onFacebookTwitterLinkedInRedditWechat Abstract This note is a corrigendum for the paper ‘Public-key encryption indistinguishable under plaintext-checkable attacks’, IET Information Security (2016), 10(6): 288, http://doi.org/10.1049/iet-ifs.2015.0500. Yu Yu pointed out a mistake in the construction in [1, Section 5.2], where an IND–CPA encryption scheme was being used in the second flow of the protocol, instead of an IND-PCA scheme. This optimisation is only possible in the three-flow variant, with an additional one-time signature. Using an IND-PCA encryption scheme slightly decreases the efficiency of the construction in [1], but it does not change the fact that the most efficient constructions remain the with group elements in two flows, and the with ten group elements in a single round of communication, both under the sole assumption. The corrected (and corresponding instantiation ) is provided in Section 1. The mistake comes from an incorrect game transition in the security proof of the , as explained in Section 2. A similar incorrect game transition was used in the security proof of the , but in that case, the original scheme is secure. Only the proof needs to be slightly modified. A fix for the proof of the is provided in Section 3. 1 and We provide the fixed generic construction in Fig. 1. It requires an IND-PCA encryption scheme with a , and an IND-PCA encryption scheme with a . The instantiation using the Short Cramer–Shoup encryption scheme is provided in Fig. 2. It is based on the plain assumption and consists of five group elements to be sent by the client and four group elements by the server, within two flows only. They both have to compute 15 exponentiations. Fig. 1Open in figure viewerPowerPoint Generic construction Fig. 2Open in figure viewerPowerPoint 2 Security of Theorem 1 below replaces Theorem 1 from [1]. Theorem 1.Suppose that the two s used in are perfectly smooth. Then for the construction, the advantage of any adversary in the BPR security game (either with basic freshness and dynamic corruptions or with forward-secure freshness in the AFP setting but only with static corruptions) is where t is approximately the running time of , and are the number of Execute and Send -queries, n is the entropy of both the projected keys and the ciphertexts, and m is the entropy of the passwords. Proof.We only highlight the differences regarding the original proof. The issue was in Game G9: smoothness cannot be used directly to argue that the session key K can be chosen uniformly at random in case 4, because the hashing key might have been used to compute some (see Game G7, case 3). The fixed proof works as follows.Game G7 is replaced by Game , which is the same as Game G7, except in case 3: when the received message by has been generated by the simulator in the name of , and when S and C are compatible, then we do not change anything in Game compared to G6. We can argue as in the original proof that: .Games G8 and G9 are removed and replaced by the three games , , and described below.Game applies the same changes as Game in [1]. This time, smoothness can be used to argue that: , as each hashing key generated by the simulator is used only once. In this game, if Win is not set, the keys generated by simulated parties are random, except in the following case: when the adversary sends to a message through a -query that has been generated by the simulator in the name of , and S and C are compatible. Note that, in that latter case, if the message sent back by the simulator in the name of is sent by the adversary to , then will output the same key as per case 3 of Game . Furthermore, the computation of in this case is the only time that the simulator needs to know .In Game , we replace all the hash values in the case above by a uniformly random value. To prove indistinguishability, we use for that the fact that thanks to the security property of , the hash value of a ciphertext of the correct password looks uniformly random, even given the projection key , when the adversary does not know the randomness used to generate . This property is called pseudo-randomness and we use it in a classical sequence of hybrids for each . Pseudo-randomness can be proven by the following sequence of games: (1) computing using instead of and (perfectly indistinguishable by correctness of the SPHF), (2) changing to a ciphertext of the dummy password (indistinguishable under ), (3) using smoothness to replace by a uniform value, and (4) changing back to a ciphertext of the real password . We thus get: , where is the number of -queries. In Game , is no longer used by the simulator to compute hash values.In Game , we replace by encryption of the dummy password . Using a classical hybrid technique, one thus gets , where is the number of -queries.We remark that Game is the same as Game in the original proof. □ 3 Security of In order to fix the proof of security of , Theorem 2 below should replace Theorem 3 from [1]. Theorem 2.Suppose that the two used in are perfectly smooth. Then, for the construction, the advantage of any adversary in the BPR security game (either with basic freshness and dynamic corruptions or with forward-secure freshness in the AFP setting but only with static corruptions) is where t is approximately the running time of , and are the number of and -queries, n is the entropy of both the projected keys and the ciphertexts, and m is the entropy of the passwords. Proof.The issue was in Game : smoothness cannot be used directly to argue that the session key K can be chosen uniformly at random in case 4, because the hashing key might have been used to compute some (because of case 3). The fix is similar except that the hybrid sequence for Game above is slightly more involved, and uses [2, Lemma 1] The fixed proof works as follows:Game is replaced by Game , which is the same as Game , except in case 3: when the received message by has been generated by the simulator in the name of , and when V and U are compatible, then we still compute using and . Also, in Game , we compute using and . With this change, the claim that is valid. We then remark that if is not set in Game , then the keys generated by simulated parties are random, except in the following case: when the adversary sends to a message through a -query that has been generated by the simulator in the name of , and V and U are compatible. Furthermore, the computation of and in this case is the only time that the simulator needs to know the randomness and of the ciphertexts and .We now add a game: Game . In Game , we replace all the hash values and in the case above by uniformly random values. We use [2, Lemma 1] where IND-CCA is replaced by IND-PCA (i.e. replacing the decryption oracle by the Oracle) and get: (the factor comes from the fact that [2, Lemma 1] uses the IND-PCA/IND-CCA property twice for each pair and : once to replace the ciphertext by a ciphertext of a dummy password and once to replace it back by the ciphertext of the correct password). In Game , the randomness of the ciphertexts is no longer used by the simulator to compute hash values.We then can proceed to Game of the original proof. □ 4 References 1Abdalla, M., Benhamouda, F., Pointcheval, D.: ‘Public-key encryption indistinguishable under plaintext-checkable attacks’, IET Inf. Sec., 2016, 10, (6), pp. 288– 303 2Katz, J., Vaikuntanathan, V.: ‘Round-optimal password-based authenticated key exchange’, J. Cryptol., 2013, 26, (4), pp. 714– 743 Volume14, Issue3May 2020Pages 365-366 FiguresReferencesRelatedInformation