PGP security questions: algorithms, key sizes, quantum, EFAIL

The building blocks GnuPG uses by default (Ed25519 signatures, Curve25519 encryption, AES and SHA-2 hashes) have no known practical attacks. The current standard, RFC 9580 (July 2024), also removed or deprecated the weak parts that older versions allowed: it forbids new signatures with MD5, SHA-1 or RIPEMD-160, forbids encrypting with IDEA, Triple-DES or CAST5, and requires authenticated encryption (OCB mode) support.

The weak points are around the cryptography: malware on your computer, a weak passphrase, a public key you never verified, or decrypted text shown in an unsafe way. The questions below cover each of these.

No. Each message is encrypted with a random session key. With AES-128 there are 2^128 possible keys, about 3.4 × 10^38. Suppose an attacker could test a billion billion (10^18) keys per second. Trying them all would take 3.4 × 10^38 ÷ 10^18 = 3.4 × 10^20 seconds. A year has about 3.15 × 10^7 seconds, so that is roughly 1.1 × 10^13 years: about 11 trillion years. AES-256 has 2^128 times more keys again.

The public-key part is attacked differently (by factoring for RSA, by discrete logarithms for elliptic curves), but at the sizes used today those attacks are also far out of reach for ordinary computers.

• New keys: the GnuPG default since version 2.3.0 (2021) is Ed25519 for the primary (signing) key and Curve25519 (shown as cv25519) for the encryption subkey. RFC 9580 makes Ed25519 and X25519 mandatory for all implementations.
• RSA: only if you must talk to old software. RFC 9580 forbids generating RSA keys smaller than 3,072 bits, says smaller keys should not be used, and forbids using keys under 2,048 bits at all. If you create RSA today, use 3072 or 4096 bits.
• Avoid: DSA and Elgamal (RFC 9580 forbids generating them), 1024-bit keys of any kind, and anything from PGP 2.x.

Key choices are covered in more detail in keys.

A large enough quantum computer would break the public-key algorithms OpenPGP has always relied on: RSA (factoring) and the elliptic-curve and Elgamal schemes (discrete logarithms). RFC 9980 calls such a machine a "cryptographically relevant quantum computer". No such machine is publicly known to exist. Symmetric ciphers are much less affected; GnuPG treats AES-256 as quantum-resistant.

The risk that matters for encryption is "record now, decrypt later": someone who stores your encrypted messages today could decrypt them if such a computer is built in the future.

The IETF published RFC 9980, "Post-Quantum Cryptography in OpenPGP", as a Proposed Standard in June 2026. It extends RFC 9580 with:

• encryption with ML-KEM (formerly CRYSTALS-Kyber) combined with X25519 or X448;
• signatures with ML-DSA (formerly Dilithium) combined with Ed25519 or Ed448;
• stand-alone SLH-DSA (formerly SPHINCS+) hash-based signatures.

The ML-KEM and ML-DSA schemes are "composite": a post-quantum and a traditional algorithm are used together, so the result stays secure as long as one of them holds. Every RFC 9980 implementation must support ML-KEM-768+X25519 and ML-DSA-65+Ed25519. As of November 2026 the OpenPGP working group is still working on a further draft with NIST and Brainpool curve combinations.

Yes, for encryption. GnuPG 2.5 can create a key with an ECC primary key and a composite Kyber+ECC encryption subkey, either with the "ECC and Kyber" choice in gpg --full-generate-key or with:

gpg --quick-gen-key 'Alice Example <alice@example.org>' pqc default 3y

Be aware of three limits as of November 2026. First, this "pqc" key type follows GnuPG's LibrePGP Kyber design and is stored as a version 5 key; GnuPG 2.5.23 added an --allow-9980 option for the RFC 9980 formats, but the GnuPG developers recommend it only where policy demands those formats. Second, many other OpenPGP programs cannot yet read these keys, so your contacts may not be able to encrypt to you. Third, GnuPG's release notes so far describe post-quantum encryption only, not post-quantum signatures.

EFAIL, published in May 2018, showed how an attacker who had captured an encrypted email could make the victim's own mail program leak the decrypted text. There were two kinds:

• Direct exfiltration: bugs in how some mail clients (the researchers name Apple Mail, iOS Mail and Thunderbird) assembled HTML from several MIME parts, so decrypted text ended up in an image URL sent to the attacker.
• CFB gadget attacks (CVE-2017-17688 for OpenPGP): changing the encrypted data itself. OpenPGP's integrity check (the MDC) detects this, but several clients only showed a warning and displayed the modified text anyway.

GnuPG 2.2.8 (June 2018) made a missing integrity check a hard decryption failure, and RFC 9580 adds authenticated encryption. Keep your mail client and GnuPG up to date, do not turn off integrity errors with --ignore-mdc-error, and consider turning off HTML display of incoming mail, which the researchers listed as a short-term defense.

Partly. In 2020 the "SHA-1 is a Shambles" researchers produced the first practical chosen-prefix collision for SHA-1 and used it to create two PGP keys with different user IDs whose certification signatures collide. A signature on one key could then be copied onto a key carrying someone else's name (CVE-2019-14855). They estimated the cost at about 45,000 US dollars at the time.

GnuPG 2.2.18 (November 2019) responded by treating SHA-1-based key certifications created after January 19, 2019 as invalid, and RFC 9580 forbids new signatures with SHA-1. Version 4 fingerprints are still SHA-1 hashes; RFC 9580 notes this is unavoidable as long as version 4 keys are supported, and its version 6 keys use SHA-256 fingerprints instead. If your key's preferences or old signatures still use SHA-1, update them (see keys).

Only in a limited sense. Each message has its own session key, so revealing one session key does not expose other messages. But everything encrypted to your key can be decrypted by anyone who later gets your private key and passphrase. Messaging apps designed for forward secrecy change keys constantly; OpenPGP does not. Using encryption subkeys that you replace every year or two, and deleting old ones you no longer need, limits the damage.

Use several random words, chosen by dice or a password generator rather than by you. Example of the arithmetic: a word list with 7,776 entries (all combinations of five dice, 6^5) gives about 12.9 bits per word, so six random words give about 77 bits, or roughly 2 × 10^23 possibilities. Song lyrics, quotations and personal details are much weaker than their length suggests, because attackers try them first. Store the passphrase in a password manager or write it down and keep it somewhere safe.

Then the private key cannot be used, by you or anyone else. There is no recovery service and no back door. Revoke the key with the revocation certificate that GnuPG saved in ~/.gnupg/openpgp-revocs.d/ when you created it, publish the revocation, and make a new key. See revoking a key.

Not straight away: the private key is encrypted with your passphrase. But the thief can try passphrases offline as fast as their hardware allows, so a weak passphrase will fall. If you think a key was copied, revoke it and create a new one. Keeping the private key on a smartcard or security token, which never lets the key leave the device, removes this risk for stolen files. See smartcards and YubiKey.

Only if you trust everyone with administrator rights on it. The root user can read memory, swap space, and anything you type. Keep private keys on your own device or a smartcard, and do decryption and signing there. The same goes for laptops and phones you do not control.