GPG and OpenPGP are both advancing toward post-quantum cryptography… but not together.
For more than 25 years, the former implemented the latter, now defined in RFC 4880. But their shared history is coming to an end. GPG had formalized its distancing in 2023, amid disagreements over the evolution of OpenPGP. It created a fork: LibrePGP, integrated starting with its 2.5.0 release, issued in the summer of 2024.
The 2.4.x branch remained on OpenPGP, but it reaches end-of-life in mid-2026. PGP thus recommends switching to 2.5.x, intended to serve as a transition toward the next “real” stable version: 2.6.
Aside from the shift to LibrePGP, the main novelty is experimental support for post-quantum cryptography. Specifically, the Kyber algorithm (ML-KEM, FIPS 203). It is a key encapsulation mechanism. The GPG project did not implement it alone: it combined it with a classical algorithm (X25519).
Seven post-quantum cryptography options in draft at OpenPGP
Within the IETF, the OpenPGP working group conducts its own work. Its draft standard currently implements ML-KEM in a hybrid configuration. The same goes for ML-DSA (signature). Considered more secure at the expense of slower operation and heavier signatures, SLH-DSA is implemented autonomously.
| ID | Signature algorithms | Security level |
|---|---|---|
| 30 | ML-DSA-65 + Ed25519 | Mandatory (MUST) |
| 31 | ML-DSA-87 + Ed448 | Recommended (SHOULD) |
| 32 | SLH-DSA-SHAKE-128s | Possible (MAY) |
| 33 | SLH-DSA-SHAKE-128f | Possible (MAY) |
| 34 | SLH-DSA-SHAKE-256s | Possible (MAY) |
| ID | Encapsulation algorithms | Security level |
|---|---|---|
| 35 | ML-KEM-768 + X25519 | Mandatory (MUST) |
| 36 | ML-KEM-1024 + X448 | Recommended (SHOULD) |
The SHOULD-level requirements can be ignored when targeting resource-constrained environments.
Each algorithm or combination of algorithms offers two levels of security to allow a performance trade-off. At the base security level, the SLH-DSA algorithms provide an additional compromise between signature generation time (128f is faster) and its size (128s is smaller).
For interoperability, OpenPGP recommends options 31 and 36, though they are not required for compliance. With ML-KEM, the two encapsulations (classic and post-quantum) are performed in parallel, the whole being combined to obtain a secret. The ML-DSA and EdDSA signatures, by contrast, are independent.
The PCQ@Thunderbird project implements this draft, with funding from the German ANSSI. Proton has also integrated it, in its OpenGPG.js and GopenPGP libraries. SequoiaPGP as well, starting with its OpenSSL-backed backend.
The focal point of the initiative is in Germany. The draft is indeed co-signed by Stavros Kousidis (consultant for the German ANSSI) and Falko Strenzke (systems architect at MTG AG, a provider of cryptographic technologies). It is also co-signed by Aron Wussler (back-end engineer in Proton’s crypto team, the Swiss publisher).
The IETF has another draft — carried by a different working group — to add support for symmetric keys to OpenPGP, more resistant to quantum computers.
