Can We Trust Cryptographic Software? Cryptographic Flaws in GNU Privacy Guard v1.2.3

  • Phong Q. Nguyen
Part of the Lecture Notes in Computer Science book series (LNCS, volume 3027)


More and more software use cryptography. But how can one know if what is implemented is good cryptography? For proprietary software, 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 Internet application of cryptography: secure email. We analyze parts of the source code of the latest version of GNU Privacy Guard (GnuPG or GPG), a free open source alternative to the famous PGP software, compliant with the OpenPGP standard, and included in most GNU/Linux distributions such as Debian, MandrakeSoft, Red Hat and SuSE. We observe 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.


Public-key cryptography GnuPG GPG OpenPGP Cryptanalysis RSA ElGamal Implementation 


  1. 1.
    Bellovin, D.M.: Cryptography and the Internet. In: Krawczyk, H. (ed.) CRYPTO 1998. LNCS, vol. 1462, p. 46. Springer, Heidelberg (1998)Google Scholar
  2. 2.
    Bleichenbacher, D.: On the generation of one-time keys in DSS. Manuscript (February 2001). Result presented at the Monteverita workshop of March 2001Google Scholar
  3. 3.
    Bleichenbacher, D.: Generating ElGamal signatures without knowing the secret key. In: Maurer, U.M. (ed.) EUROCRYPT 1996. LNCS, vol. 1070, pp. 10–18. Springer, Heidelberg (1996)Google Scholar
  4. 4.
    Bleichenbacher, D.: Chosen ciphertext attacks against protocols based on the RSA encryption standard PKCS #1. In: Krawczyk, H. (ed.) CRYPTO 1998. LNCS, vol. 1462, pp. 1–12. Springer, Heidelberg (1998)Google Scholar
  5. 5.
    Boneh, D., Joux, A., Nguyen, P.Q.: Why textbook ElGamal and RSA encryption are insecure. In: Okamoto, T. (ed.) ASIACRYPT 2000. LNCS, vol. 1976, pp. 30–43. Springer, Heidelberg (2000)CrossRefGoogle Scholar
  6. 6.
    Callas, J., Donnerhacke, L., Finney, H., Thayer, R.: OpenPGP message format: Request for Comments 2440, Available as
  7. 7.
    Coron, J.-S., Naccache, D., Stern, J.P.: On the security of RSA padding. In: Wiener, M. (ed.) CRYPTO 1999. LNCS, vol. 1666, pp. 1–18. Springer, Heidelberg (1999)Google Scholar
  8. 8.
    European Union. European project IST-1999-12324: New European Schemes for Signatures, Integrity, and Encryption (NESSIE),
  9. 9.
    Goldberg, I., Wagner, D.: Randomness and the Netscape browser. Dr Dobb’s (January 1996)Google Scholar
  10. 10.
    GPG. The GNU privacy guard,
  11. 11.
    Gutmann, P.: Software generation of practically strong random numbers. In: Proc. of the 7th Usenix Security Symposium (1998)Google Scholar
  12. 12.
    Gutmann, P.: Lessons learned in implementing and deploying crypto software. In: Proc. of the 11th Usenix Security Symposium (2002)Google Scholar
  13. 13.
    Howgrave-Graham, N.A., Smart, N.P.: Lattice attacks on digital signature schemes. Design, Codes and Cryptography 23, 283–290 (2001)zbMATHCrossRefMathSciNetGoogle Scholar
  14. 14.
    IEEE. P1363: Standard specifications for public-key cryptography, Available at
  15. 15.
    Cryptrec, I.: Evaluation of cryptographic techniques, Available at
  16. 16.
    Jallad, K., Katz, J., Schneier, B.: Implementation of chosen-ciphertext attacks against PGP and GnuPG. In: Chan, A.H., Gligor, V.D. (eds.) ISC 2002. LNCS, vol. 2433, p. 90. Springer, Heidelberg (2002)CrossRefGoogle Scholar
  17. 17.
    Kaliski, B.: PKCS #1: RSA encryption version 1.5: Request for Comments 2313, Available as
  18. 18.
    Katz, J., Schneier, B.: A chosen ciphertext attack against several E-Mail encryption protocols. In: Proc. of the 9th Usenix Security Symposium (2000)Google Scholar
  19. 19.
    Koch, W.: GnuPG’s ElGamal signing keys compromised. Internet public announcement on November 27 (2003)Google Scholar
  20. 20.
    RSA Labs. PKCS #1: RSA cryptography standard, Available at
  21. 21.
    Manger, J.: A chosen ciphertext attack on RSA Optimal Asymmetric Encryption Padding (OAEP) as standardized in PKCS #1 v2.0. In: Kilian, J. (ed.) CRYPTO 2001. LNCS, vol. 2139, pp. 230–231. Springer, Heidelberg (2001)CrossRefGoogle Scholar
  22. 22.
    Nguyen, P.Q., Shparlinski, I.E.: The insecurity of the Digital Signature Algorithm with partially known nonces. Journal of Cryptology 15(3) (2002)Google Scholar
  23. 23.
    Nguyen, P.Q., Stehlé, D.: Low-dimensional lattice basis reduction revisited. In: Buell, D.A. (ed.) ANTS 2004. LNCS, vol. 3076, pp. 338–357. Springer, Heidelberg (2004)CrossRefGoogle Scholar
  24. 24.
    Nguyen, P.Q., Stern, J.: The two faces of lattices in cryptology. In: Silverman, J.H. (ed.) CaLC 2001. LNCS, vol. 2146, pp. 146–180. Springer, Heidelberg (2001)CrossRefGoogle Scholar
  25. 25.
    van Oorschot, P.C., Wiener, M.J.: On Diffie-Hellman key agreement with short exponents. In: Maurer, U.M. (ed.) EUROCRYPT 1996. LNCS, vol. 1070, pp. 332–343. Springer, Heidelberg (1996)Google Scholar
  26. 26.
  27. 27.
    PGP. Pretty good privacy,
  28. 28.
    Schneier, B.: Security in the real world: How to evaluate security technology. Computer Security Journal XV(4) (1999)Google Scholar
  29. 29.
    Shoup, V.: Number Theory C++ Library (NTL) version 5.3.1, Available at
  30. 30.
    Stern, J., Pointcheval, D., Malone-Lee, J., Smart, N.P.: Flaws in applying proof methodologies to signature schemes. In: Yung, M. (ed.) CRYPTO 2002. LNCS, vol. 2442, pp. 93–110. Springer, Heidelberg (2002)CrossRefGoogle Scholar

Copyright information

© Springer-Verlag Berlin Heidelberg 2004

Authors and Affiliations

  • Phong Q. Nguyen
    • 1
  1. 1.CNRS/École normale supérieure, Département d’informatiqueParis Cedex 05France

Personalised recommendations