What is your plan about the compatibility? 1: new versions can decrypt old versions' ciphertexts 2: old versions can decrypt new versions' ciphertexts, and new versions can decrypt old versions' ciphertexts
On Tuesday, May 22, 2018 at 10:33:26 AM UTC-7, Weikeng Chen wrote: > > So as Jeffrey forwarded to the public mail listing, I would like to add a > one-paragraph note for the public: > > Today, mostly ElGamal is used for hybrid encryption, i.e., encrypts > a symmetric key. For this setting, this attack is not useful. > The attack is only useful if you encrypt plain messages. And the > attack can only distinguish some messages, but not recover a message. > > That is also why this is a low-risk security issue. > > > On Tuesday, May 22, 2018 at 3:47:05 AM UTC-7, Jeffrey Walton wrote: >> >> FYI... >> >> ---------- Forwarded message ---------- >> From: Weikeng Chen <w...@berkeley.edu> >> Date: Tue, May 22, 2018 at 3:55 AM >> Subject: Report a (not severe) security bug of CryptoPP in ElGamal >> To: nolo...@gmail.com >> >> Hi Jeffrey, >> >> Sorry. This is the only way we can find a maintainer of CryptoPP in >> private, >> which consolidates a responsible disclosure. >> >> CryptoPP uses padding to secure ElGamal. But the padding is not >> sufficient. >> >> In more details, CryptoPP uses a prime-order group with a QR generator >> for ElGamal. That is great! >> (QR means quadratic residue, QNR means quadratic non-residue.) >> But when CryptoPP encodes a message, the message may be encoded into a >> QR or into a QNR, depending on the message and the random pad added to >> the message. >> >> It is possible that given a message m, it has 48% possibility to >> become a QR, and 52% to become a QNR. >> Or, it is also possible that for another message m', it has 52% >> possibility to become a QR, and 48% as a QNR. >> >> There is a *Difference* between different messages, which may lead to >> an attack that guesses the message. >> Because it is easy to determine whether a ciphertext is QR or QNR, and >> it implies whether the padded message is QR or QNR. >> >> We know such explanation is usually not intuitive -- we had very >> terrible experience communicating with PyCryptodome and libgcrypt, so >> far they refuse to fix completely. >> So below is a PoC for CryptoPP, with a preliminary patch: >> https://github.com/weikengchen/attack-on-cryptopp-elgamal >> which the attack abuses the above possibility distribution difference >> to guess the message from the ciphertext. >> >> This security bug is not severe, because, in the real world, people >> use ElGamal mostly to encrypt a symmetric key (i.e., hybrid >> encryption). >> It is secure if ElGamal encrypts a symmetric key. Therefore, we do >> make this repo of the PoC public as it does not lead to a security >> risk to existing systems. >> >> So my report concludes. It is not easy to fix -- because you need to >> change the implementation of ElGamal encryption in CryptoPP to >> proceed, which hurts the compatibility. >> The fix in the patch of that repo is to encode the message into a QR, >> not using padding. >> >> Let me know your idea of what we should do the next. >> >> Weikeng >> > -- You received this message because you are subscribed to "Crypto++ Users". More information about Crypto++ and this group is available at http://www.cryptopp.com and http://groups.google.com/forum/#!forum/cryptopp-users. --- You received this message because you are subscribed to the Google Groups "Crypto++ Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to cryptopp-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
