Can We Trust Cryptographic Software? Cryptographic Flaws in GNU Privacy Guard v1.2.3 Phong Q. Nguyen CNRS/Ecole´ normale sup´erieure D´epartement d’informatique 45 rue d’Ulm, 75230 Paris Cedex 05, France. [email protected] http://www.di.ens.fr/˜pnguyen Abstract. More and more software use cryptography. But how can one know if what is implemented is good cryptography? For proprietary soft- ware, one cannot say much unless one proceeds to reverse-engineering, and history tends to show that bad cryptography is much more frequent than good cryptography there. Open source software thus sounds like a good solution, but the fact that a source code can be read does not imply that it is actually read, especially by cryptography experts. In this paper, we illustrate this point by examining the case of a basic In- ternet application of cryptography: secure email. We analyze parts of thesourcecodeofthelatestversionofGNUPrivacyGuard(GnuPGor GPG), a free open source alternative to the famous PGP software, com- pliant with the OpenPGP standard, and included in most GNU/Linux distributions such as Debian, MandrakeSoft, Red Hat and SuSE. We ob- serve several cryptographic flaws in GPG v1.2.3. The most serious flaw has been present in GPG for almost four years: we show that as soon as one (GPG-generated) ElGamal signature of an arbitrary message is released, one can recover the signer’s private key in less than a second on a PC. As a consequence, ElGamal signatures and the so-called ElGamal sign+encrypt keys have recently been removed from GPG. Fortunately, ElGamal was not GPG’s default option for signing keys. Keywords: Public-key cryptography, GnuPG, GPG, OpenPGP, Crypt- analysis, RSA, ElGamal, Implementation. 1 Introduction With the advent of standardization in the cryptography world (RSA PKCS [20], IEEE P1363 [14], CRYPTREC [15], NESSIE [8], etc.), one may think that there is more and more good cryptography. But as cryptography becomes “global”, how can one be sure that what is implemented in the real world is actually good cryptography? Numerous examples (such as [4,2,21]) have shown that the frontier between good cryptography and bad cryptography is very thin. For proprietary software, it seems difficult to make any statement unless one proceeds C. Cachin and J. Camenisch (Eds.): EUROCRYPT 2004, LNCS 3027, pp. 555–570, 2004. c International Association for Cryptologic Research 2004 556 Phong Q. Nguyen to the tedious task of reverse-engineering. If a proprietary software claims to implement 2048-bit RSA and 128-bit AES, it does not say much about the actual cryptographic security: which RSA is being used? Could it be textbook RSA [5] (with zero-padding) encrypting a 128-bit AES key with public exponent 3? Are secret keys generated by a weak pseudo-random number generator like old versions of Netscape [9]? Who knows if it is really RSA–OAEP which is implemented [21]? With proprietary software, it is ultimately a matter of trust: unfortunately, history has shown that there is a lot of bad cryptography in proprietary software (see for instance [28,12] for explanations). Open source software thus sounds like a good solution. However, the fact that a source code can be read does not necessarily imply that it is actually read, especially by cryptography experts. The present paper illustrates this point by examining the case of “perhaps the most mature cryptographic technology in use on the Internet” (according to [1]): secure email, which enables Internet users to authentify and/or encrypt emails. Secure email became popular in the early 90s with the appearance of the now famous Pretty Good Privacy (PGP) [27] software developed by Phil Zimmermann in the US. Not so long ago, because of strict export restrictions and other US laws, PGP was unsuitable for many areas outside the US. Although the source code of PGP has been published, it is unknown whether future versions of PGP will be shipped with access to the source code. GNU Privacy Guard [10] (GnuPG, or GPG in short) was developed in the late 90s as an answer to those PGP issues. GPG is a full implementation of OpenPGP [26], the Internet standard that extends PGP. GPG has been released as free software under the GNU General Public License (GNU GPL): As such, full access to the source code is provided at [10], and GPG can be viewed as a free replacement for PGP. The German Federal Ministry of Economics and Technology granted funds for the further development of GPG. GPG has a fairly significant user base: it is included in most GNU/Linux distributions, such as Debian, MandrakeSoft, Red Hat and SuSE. The first stable version of GPG was released on September 7th, 1999. Here, we review the main public- key aspects of the source code of v1.2.3, which was the current stable version (released on August 22nd, 2003) when this paper was submitted to Eurocrypt ’04. Our comments seem to also apply to several previous versions of GPG. However, we stress that our analysis is not claimed to be complete, even for the public-key aspects of GPG. We observe several cryptographic flaws in GPG v1.2.3. The most serious flaw (which turns out to have been present in GPG for almost four years) is related to ElGamal signatures: we present a lattice-based attack which recovers the signer’s private key in less than a second on a PC, given any (GPG-generated) ElGa- mal signature of a (known) arbitrary message and the corresponding public key. This is because both a short private exponent and a short nonce are used for the generation of ElGamal signatures, when the GPG version in use is between 1.0.2 (January 2000) and 1.2.3 (August 2003). As a result, GPG–ElGamal signing keys have been considered compromised [19], especially the so-called primary ElGa- Can We Trust Cryptographic Software? 557 mal sign+encrypt keys: with such keys, one signature is always readily available, because such keys automatically come up with a signature to bind the user iden- tity to the public key, thus leaking the private key used for both encryption and signature. Hence, ElGamal signatures and ElGamal sign+encrypt keys have recently been removed from GPG (see [10] for more information). We notice that GPG encryption provides no chosen-ciphertext security, due to its compliance with OpenPGP [26], which uses the old PKCS #1 v1.5 stan- dard [17]: Bleichenbacher’s chosen-ciphertext attack [4] applies to OpenPGP, ei- ther when RSA or ElGamal is used. Although the relevance of chosen-ciphertext attacks to the context of email communications is debatable, we hope that OpenPGP will replace PKCS #1 v1.5 to achieve chosen-ciphertext security. The other flaws do not seem to lead to any reasonable attack, they only underline the lack of state-of-the-art cryptography in GPG and sometimes OpenPGP. It is worth noting that the OpenPGP standard is fairly loose: it gives non-negligible freedom over the implementation of cryptographic functions, especially regard- ing key generation. Perhaps stricter and less ambiguous guidelines should be given in order to decrease security risks. The only published research on the cryptographic strength of GPG we are aware of is [18,16], which presented chosen-ciphertext attacks with respect to the symmetric encryption used in PGP and GPG. The rest of the paper is organized as follows. In Section 2, we give an overview of the GPG software v1.2.3. In Section 3, we review the GPG implementation of ElGamal and present the attack on ElGamal signatures. In Section 4, we review the GPG implementation of RSA. There is no section devoted to the GPG implementation of DSA, since we have not found any noteworthy weakness in it. In Appendix A, we give a brief introduction to lattice theory, because the attack on ElGamal signatures uses lattices. In Appendix B, we provide a proof (in an idealized model) of the lattice-based attack on ElGamal signatures. 2 An Overview of GPG v1.2.3 GPG v1.2.3 [10] supports ElGamal (signature and encryption), DSA, RSA, AES, 3DES, Blowfish, Twofish, CAST5, MD5, SHA-1, RIPE-MD-160 and TIGER. GPG decrypts and verifies PGP 5, 6 and 7 messages: It is compliant with the OpenPGP standard [26], which is described in RFC 2440 [6]. GPG provides secrecy and/or authentication to emails: it enables users to encrypt/decrypt and/or sign/verify emails using public-key cryptography. The public-key infrastructure is the famous web of trust: users certify public key of other users. GPG v.1.2.3 allows the user to generate several types of public/private keys, with the command gpg --gen-key: – Choices available in the standard mode: • (1) DSA and ElGamal: this is the default option. The DSA keys are signing keys, while the ElGamal keys are encryption keys (type 16 in the OpenPGP terminology). 558 Phong Q. Nguyen • (2) DSA: only for signatures. • (5) RSA: only for signatures. – Additional choices available in the expert mode: • (4) ElGamal for both signature and encryption. In the OpenPGP termi- nology, these are keys of type 20. • (7) RSA for both signature and encryption. In particular, an ElGamal signing key is also an encryption key, but an ElGamal encryption key may be restricted to encryption. In GPG v1.2.3, ElGamal signing keys cannot be created unless one runs the expert mode: however, this was not always the case in previous versions. For instance, the standard mode of GPG v1.0.7 (which was released in April 2002) proposes the choices (1), (2), (4) and (5).