Post-quantum cryptography is coming to OpenPGP. Over the past three years, several parties have collaborated on a new specification within the IETF OpenPGP working group. That document, Post-Quantum Cryptography in OpenPGP, is making its final steps towards ratification. During the last year, we’ve implemented the standard in Sequoia, and exposed the functionality in various components. In this blog post, I’ll explain what post-quantum cryptography is, why we’ve implemented it, and how to use it.
A quantum computer is a type of computer that makes use of quantum physics. In particular, a quantum computer makes use of the principle of superposition, which says that a quantum system can be in multiple states at the same, which allows multiple computations to be done simultaneously. By leveraging this, some problems that take such a long time to solve using a traditional computer that they are effectively intractable can be solved in a small amount of time using a quantum computer.
Several decades ago, Peter Shor demonstrated this speedup endangers cryptography, which relies on some problems being hard to solve. An example of such a problem is factoring integers. The security of the RSA algorithm relies on this problem being difficult. But factoring is easy for a sufficiently powerful quantum computer.
Since then researchers have been looking for problems that are hard for both traditional and quantum computers, and designing cryptographic algorithms around them. Post-quantum cryptography refers to these algorithms.
The good news is that no current quantum computers are powerful enough to break current cryptography. Some people are nervous that they will arrive soon, and argue that we need to hedge our bets, and prepare for the worst. Others, like cryptographer Peter Gutmann, think post-quantum cryptography is a Heffalump: an imagined threat. If one were feeling particularly incharitable, one might argue that the push for post-quantum cryptography is a strategy by those in power to distract those able to develop tools that protect people’s privacy and security by coercing them to waste time on something that doesn’t matter.
Whatever your opinion, as Clemens Lang, the Crypto Team Product Owner at Red Hat, explained at the recent OpenSSL conference: some governments will require the tools that they use to support post-quantum cryptography in the near future. This means that a lot of companies want post-quantum cryptography, and people will begin to expect it from serious projects.
Unfortunately, there is a lot less confidence in many of the post-quantum algorithms than in traditional cryptography. Indeed, one of the finalist’s in NIST’s competition, SIKE, was recently broken. To mitigate this risk, OpenPGP doesn’t just use post-quantum algorithms. Instead, OpenPGP pairs most of the post-quantum algorithms with traditional algorithms. Using this construct, a message’s integrity or confidentiality is only compromised if both algorithms are broken.
The other issue with post-quantum algorithms is that they are slow and have large artifacts. There is not much that can be done about this. But, since post-quantum cryptography is only needed for asymmetric cryptography (hashes and symmetric algorithms appear to be quantum resistant), and network bandwidth and storage have grown enormously, this problem is limited.
OpenPGP
Post-Quantum Cryptography in OpenPGP adds seven new algorithms (or pairs of algorithms) to OpenPGP:
- ML-DSA-65 and Ed25519
- ML-DSA-87 and Ed448
- SLH-DSA-128s
- SLH-DSA-128f
- SLH-DSA-256s
- ML-KEM-768 and X25519
- ML-KEM-1024 and X448
The ML-DSA-based and SLH-DSA-based algorithms are both signing algorithms. The cryptography community’s confidence in ML-DSA’s security is good, but not extremely high. As such, it is paired with Ed25519 or Ed448. The SLH-DSA algorithm is based on hash functions and the confidence in its security is very high. As such the two variants standalone. The downside of SLH-DSA is that it is slower than ML-DSA, and it produces larger artifacts. SLH-DSA’s signatures are between 8 kilobytes and 30 kilobytes large whereas an ML-DSA-65 and ML-DSA-87 signatures are 3.3 kilobytes and 4.6 kilobytes respectively. In comparison, an Ed25519 signature is just 64 bytes.
ML-KEM is an encryption algorithm, which comes in two variants with different strengths. Similar to ML-DSA, they are paired with either X25519 or X448.
If you plan to generate a post-quantum certificate, you need to choose between these algorithms. How you should choose depends on what you plan to use the certificate for. If the certificate is a general-purpose certificate, which you plan to use for day-to-day encryption, signing, and authentication, then you should use ML-DSA and ML-KEM. If you are going to create a certificate that you will only use to sign software releases, then you should consider SLH-DSA. The confidence in its security is higher, and the longer computation time and larger artifacts don’t matter in this context.
The following table, derived from tables 3 and 5 of NIST IR 8547: Transition to Post-Quantum Cryptography Standards, shows the believed strength of the post-quantum algorithms in terms of classical algorithms:
| Algorithm | Equivalent | |
|---|---|---|
| ML-DSA-65 | AES-192 | |
| ML-DSA-87 | AES-256 | |
| SLH-DSA-128s | AES-128 | |
| SLH-DSA-128f | AES-128 | |
| SLH-DSA-256s | AES-256 | |
| ML-KEM-768 | AES-192 | |
| ML-KEM-1024 | AES-256 |
As AES-128 is currently considered sufficiently secure, the ML-DSA-65, SLH-DSA-128s and ML-KEM-768 are probably sufficient.
If you decide to generate a post-quantum certificate you will have interoperability problems until implementations that support the new standard become widely deployed. We expect the post-quantum standard to be published in the first half of 2026. Shortly after it is published, we will release new versions of Sequoia that include support for post-quantum cryptography. Linux distributions like Debian and Fedora will package them, but the next version of Debian is unlikely to be released before July 2027. As such, we don’t expect using post-quantum cryptography exclusively will be reasonable for the next few years.
To mitigate this problem, you can have two certificates: one certificate that is compatible with the status quo, and one that uses post-quantum cryptography. This is what Red Hat is doing with their signing keys: they have a certificate that uses RSA, and a certificate that uses post-quantum key and will sign everything with both. This provides the added security of post-quantum cryptography to those who are willing to make the effort to install the latest software, and compatibility for those who aren’t.
Sequoia PGP
Sequoia PGP currently has five different cryptography backends. So far, we’ve only added support for post-quantum cryptography using the OpenSSL backend. We plan to add support for the other backends in the future.
We’ve made pre-releases of most of our software with support for post-quantum cryptography. Once the standard is ratified, we’ll make official releases.
To build sq with post-quantum cryptography today, you can do the
following:
$ git clone https://gitlab.com/sequoia-pgp/sequoia-sq.git
Cloning into 'sequoia-sq'...
...
$ cd sequoia-sq
$ git checkout pqc
branch 'pqc' set up to track 'origin/pqc'.
Switched to a new branch 'pqc'
$ cargo build --release --locked --no-default-features --features crypto-openssl
Finished `release` profile [optimized + debuginfo] target(s) in 49.63s
$ target/release/sq version
sq 1.4.0-pqc.1
using sequoia-openpgp 2.2.0-pqc.1
with cryptographic backend 3.5.1
Alternatively, you can install from crates.io using:
$ cargo install sequoia-sq --version 1.4.0-pqc.1 \
--locked --no-default-features --features crypto-openssl
...
Installing /home/user/.cargo/bin/sq
Installed package `sequoia-sq v1.4.0-pqc.1` (executable `sq`)
To generate a post-quantum certificate do the following:
$ export SEQUOIA_HOME=$(mktemp -d)
$ sq key generate --email postquantum@example.org \
--cipher-suite mldsa65-ed25519 --profile rfc9580 --own-key
Please enter the password to protect key (press enter to not use a password):
Please repeat the password:
- ┌ 046DDE16804E69BBC8ED42298B558A8D46487E24483F13EA78C2B8BADF56FC38
└ <postquantum@example.org>
- certification created
Transferable Secret Key.
Fingerprint: 046DDE16804E69BBC8ED42298B558A8D46487E24483F13EA78C2B8BADF56FC38
Public-key algo: ML-DSA-65+Ed25519
Secret key: Unencrypted
Creation time: 2025-11-13 17:40:12 UTC
Expiration time: 2028-11-13 11:06:33 UTC (creation time + 2years 11months 30days 9h 16m 45s)
Key flags: certification
Subkey: 8AC52BE7E37082215BAC9470297E6610B0771B8C345DAF3409F657575E5E7F69
Public-key algo: ML-DSA-65+Ed25519
Secret key: Unencrypted
Creation time: 2025-11-13 17:40:12 UTC
Expiration time: 2028-11-13 11:06:33 UTC (creation time + 2years 11months 30days 9h 16m 45s)
Key flags: signing
Subkey: C197CD47C1AEF9273B6FC122D7BFB6B573B4F9341A23B9DBC584AE2E427426F5
Public-key algo: ML-DSA-65+Ed25519
Secret key: Unencrypted
Creation time: 2025-11-13 17:40:12 UTC
Expiration time: 2028-11-13 11:06:33 UTC (creation time + 2years 11months 30days 9h 16m 45s)
Key flags: authentication
Subkey: D8EEAFE407FBCD7E1A4B9A2A6C8581B91CD408367D73DF96DE025CE9E92C4F92
Public-key algo: ML-KEM-768+X25519
Secret key: Unencrypted
Creation time: 2025-11-13 17:40:12 UTC
Expiration time: 2028-11-13 11:06:33 UTC (creation time + 2years 11months 30days 9h 16m 45s)
Key flags: transport encryption, data-at-rest encryption
UserID: <postquantum@example.org>
Certifications: 1, use --certifications to list
...
We set SEQUOIA_HOME to a temporary directory so as to not pollute
the default location.
There are two things to notice about the second command: We specified
a non-default cipher suite, mldsa65-ed25519, and an alternate
profile rfc9580 profile. The cipher suite selects a family of
algorithms. The profile indicates that we want a certificate that
uses the format specified in RFC 9580, which is the most recent
OpenPGP specification.
We need to use the new format, because with the exception of one encryption algorithm (ML-KEM-768+X25519), the post-quantum algorithms are only specified for the new certificate format. This makes sense, because a certificate that only uses post-quantum cryptography can’t be used at all by current implementations, and the only reason to extend the old format would be backwards compatibility. In contrast, most implementations ignore subkeys with an algorithm that they don’t understand. As such, supporting ML-KEM-768+X25519 encryption keys with the old format enables a quicker partial transition to post-quantum cryptography.
Using a post-quantum certificate doesn’t require anything special. For instance, here we sign and encrypt a message, and then decrypt and verify it. This is the exact same workflow as when working with non-post-quantum certificates:
$ echo hello world \
| sq encrypt --for 046DDE16804E69BBC8ED42298B558A8D46487E24483F13EA78C2B8BADF56FC38 \
--signer 046DDE16804E69BBC8ED42298B558A8D46487E24483F13EA78C2B8BADF56FC38 \
| sq decrypt
Composing a message...
- encrypted for <postquantum@example.org> (authenticated)
- using 046DDE16804E69BBC8ED42298B558A8D46487E24483F13EA78C2B8BADF56FC38
- signed by <postquantum@example.org> (authenticated)
- using 046DDE16804E69BBC8ED42298B558A8D46487E24483F13EA78C2B8BADF56FC38
Encrypted and protected using AES-256/OCB
Authenticating 046DDE16804E69BBC8ED42298B558A8D46487E24483F13EA78C2B8BADF56FC38 (<postquantum@example.org>) using the
web of trust:
Fully authenticated (120 of 120) 046DDE16804E69BBC8ED42298B558A8D46487E24483F13EA78C2B8BADF56FC38,
<postquantum@example.org>
◯─┬ B7B9A49938A752BA24B97131A9EFC260E8ED20D5
│ └ (Local Trust Root)
│
│ certified the following binding on 2025‑11‑13 as a meta-introducer (depth: unconstrained)
│
└─┬ 046DDE16804E69BBC8ED42298B558A8D46487E24483F13EA78C2B8BADF56FC38
└ <postquantum@example.org>
Authenticated signature made by 046DDE16804E69BBC8ED42298B558A8D46487E24483F13EA78C2B8BADF56FC38
(<postquantum@example.org>)
hello world
Decrypted by 046DDE16804E69BBC8ED42298B558A8D46487E24483F13EA78C2B8BADF56FC38, <postquantum@example.org> (authenticated)
1 authenticated signature.
The only noticeable difference is that the asymmetric cryptography is a bit slower, and the artifacts are large. In this case, the generated certificate is 42 kilobytes. In comparison, a certificate that only uses elliptical cryptography is 2.3 kilobytes.
$ sq cert export --cert 046DDE16804E69BBC8ED42298B558A8D46487E24483F13EA78C2B8BADF56FC38 | wc -c
42825
$ sq cert export --cert 6C54D9FAA96E3DE39FB621B3F21190C688DBD3A2 | wc -c
2322
For more information about using post-quantum cryptography to sign packages, refer to the Signing RPM packages using quantum-resistant cryptography article recently published by Red Hat.
sequoia-openpgp
Generating post-quantum certificates using sequoia-openpgp is
straightforward. You generate a certificate in the usual way, but
specify a post-quantum cipher suite. As above, we also need to
specify the RFC 9580 profile to generate a new format certificate:
use sequoia_openpgp as openpgp;
use openpgp::Profile;
use openpgp::cert::CertBuilder;
use openpgp::cert::CipherSuite;
let (cert, rev) = CertBuilder::general_purpose(Some("<post-quantum@example.org>"))
.set_profile(Profile::RFC9580)?
.set_cipher_suite(CipherSuite::MLDSA65_Ed25519)
.generate()?;
In your Cargo.toml file, be sure to specify the pre-release:
sequoia-openpgp = "2.2.0-pqc.1"
And, like above, select the OpenSSL backend when compiling your project.
Using a post-quantum certificate to, e.g., encrypt a message, does not require any other special handling.
Contributions
This project was a collaboration between Sequoia and Red Hat. On the Sequoia side, Devan Carpenter, Justus Winter, Malte Meiboom and I contributed. On the Red Hat side, significant technical and non-technical contributions came from Clemens Lang, Daiki Ueno, Jakub Jelen, Peter Vrabec, Roberto Hueso Gomez, Simo Sorce, and Stanislav Zidek. Thanks to everyone for the very nice collaboration!