Greeting everyone,
I would like to share a web app I recently developed. PQ-PGP is a self-contained browser application that implements composite post-quantum OpenPGP cryptography in accordance with RFC 9980. The application pairs a NIST-standardised lattice-based primitive (ML-KEM from FIPS 203, ML-DSA from FIPS 204) with a classical elliptic-curve primitive (X25519 or X448 for ECDH, Ed25519 or Ed448 for EdDSA) at each cryptographic operation, deriving the wrapping key from both legs via the HKDF-SHA256.
Try it (WebApp): https://sh3lly.byethost11.com/pq-pgp
Technical Report: https://github.com/AoiAsahina/PQ-PGP/blob/main/PQ-PGP.pdf
Introduction: the quantum era of PGP
Post-Quantum PGP (Pretty Good Privacy) represents the evolution of the email and file encryption standard to resist the threat of future quantum computers, which will be able to break traditional asymmetric algorithms — such as RSA and ECC — via Shor's algorithm. This technological transition is not a simple cipher upgrade; it is a complete architectural reworking of how OpenPGP derives keys, signs messages, and protects private keys at rest.
The transition is officially defined at a global level by the IETF standard RFC 9980 (Post-Quantum Cryptography in OpenPGP), published in mid-2026 as a Proposed Standard, which extends the recent Crypto Refresh of the OpenPGP standard (RFC 9580). The document defines composite schemes based on ML-KEM (formerly CRYSTALS-Kyber, FIPS 203) for encryption and ML-DSA (formerly CRYSTALS-Dilithium, FIPS 204) for signatures, paired with classical elliptic curves, as well as SLH-DSA (formerly SPHINCS+, FIPS 205) as an ultra-conservative standalone signature scheme.
Technical architecture: the PQ/T hybrid approach
Because post-quantum algorithms are relatively new compared to decades of cryptanalysis on RSA and ECC, the cryptographic community has adopted a Post-Quantum / Traditional (PQ/T) hybrid strategy, also known as a composite construction. The fundamental principle is combined security: a message remains safe as long as at least one of the two algorithms — the classical one or the post-quantum one — remains unbroken. This hedge protects simultaneously against the future quantum computer and against unknown mathematical weaknesses in the new lattice-based algorithms.
Message encryption (composite KEM)
To protect data in transit from the Harvest Now, Decrypt Later attack — intercepting encrypted data today to decrypt it in the future with a quantum computer — OpenPGP introduces composite schemes based on ML-KEM combined with elliptic curves. The process has three phases:
• 1) an ephemeral symmetric session key is generated using AES-256;
• 2) this key is encapsulated twice — once with the classical algorithm and once with the post-quantum one;
• 3) the two outputs are cryptographically combined via SHA-256-based KDFs.
The mandatory and recommended combinations defined in RFC 9980 are:
➤ MUST: ML-KEM-768 + X25519 (Algorithm ID 35) — NIST Level 3, equivalent to AES-192.
➤ SHOULD: ML-KEM-1024 + X448 (Algorithm ID 36) — NIST Level 5, equivalent to AES-256, for ultra-sensitive long-term data.
Digital signatures (authentication and integrity)
To ensure that the sender's identity cannot be forged by a quantum computer, signatures use the ML-DSA standard (FIPS 204) in composite mode, or SLH-DSA (FIPS 205) in standalone mode. In composite signatures, the application must successfully verify both signatures — the classical and the post-quantum one — to consider the message valid. SLH-DSA is instead used alone: its security relies solely on hash trees, and is therefore considered ultra-secure, but with very large signatures (7–30 KB) and high signing times.
➤ MUST: ML-DSA-65 + Ed25519 (Algorithm ID 30) — NIST Level 3.
➤ SHOULD: ML-DSA-87 + Ed448 (Algorithm ID 31) — NIST Level 5, required by CNSA 2.0 fornational-security systems.
➤ Standalone (optional): SLH-DSA-128s, SLH-DSA-128f, SLH-DSA-256s — based solely on hash functions, ideal for long-term trust anchors.
Performance impact: sizes and overhead
Post-quantum cryptography relies on lattice geometry (lattice-based cryptography). Compared to the lightweight elliptic curve cryptography, it involves a substantial increase in data sizes. In Post-Quantum OpenPGP architectures, the sizes of composite packets are given by the near-exact sum of the classical and post-quantum algorithms, plus a minimal byte overhead for v6 format encapsulation.
Argon2id: the new defense line for private keys
When you protect your OpenPGP private key with a passphrase, the software does not use the password directly; it transforms it into a symmetric cryptographic key via a key derivation function (S2K, String-to-Key, OpenPGP's equivalent of KDF). Legacy OpenPGP v4 used the Iterated and Salted S2K function based on repeated hashes (SHA-1 or SHA-256) — an approach vulnerable to massive brute-force attacks conducted via specialized hardware such as GPUs, FPGAs and ASICs, capable of computing billions of hashes per second at very low cost.
Version 6 certificates introduce support for Argon2 (S2K type 4, defined in RFC 9106), winner of the 2015 Password Hashing Competition. Specifically, OpenPGP v6 adopts the Argon2id variant, which offers optimal protection by combining resistance to side-channel attacks and resistance to parallel GPU attacks. Argon2id is a memory-hard function: it requires not only CPU computing power, but forces the hardware to allocate a significant amount of RAM for a given period of time.
Because RAM is expensive to integrate at scale on custom chips, Argon2id makes industrial brute-forcing of OpenPGP passphrases economically and technically prohibitive. Version 6 certificates store four customizable parameters in the S2K packet: the salt, the number of passes (iterations), the required memory (memory coefficient), and the degree of parallelism. The client tunes these values so that the computation takes a fraction of a second on a legitimate PC, but is devastating for an attacker on specialized hardware.
Authenticated encryption AEAD: beyond simple confidentiality
Historically, OpenPGP encrypted data using the CFB (Cipher Feedback) symmetric mode and subsequently added an integrity patch called MDC (Modification Detection Code). This system proved fragile, exposing the standard to complex cryptographic attacks such as the 2018 EFAIL vulnerabilities. Version 6 certificates solve the problem at the root by making the use of AEAD (Authenticated Encryption with Associated Data) schemes mandatory via the SEIPD v2 packet (Symmetrically Encrypted and Integrity Protected Data, version 2). AEAD combines in a single logical and mathematical pass both the encryption (confidentiality) and the computation of an authentication tag (integrity), preventing any manipulation of the ciphertext. RFC 9580 standardizes three main AEAD modes: EAX, OCB, and GCM, all usable with AES-128, AES-192, and AES-256, as well as with Camellia in 128/192/256 variants.
AES-GCM (Galois/Counter Mode)
It is the de facto standard of modern cryptography, widely used in TLS (HTTPS). It benefits from massive hardware acceleration at the CPU level — Intel AES-NI and ARMv8 cryptography extensions — and is supported by every cryptographic library on the planet. GCM encrypts the data stream and generates a 128-bit GMAC authentication tag. If an attacker alters even a single bit of the ciphertext during transit, decryption fails instantly before exposing any fragment of plaintext.
AES-OCB (Offset Codebook Mode)
OCB is an exceptionally efficient AEAD mode, often preferred within the OpenPGP v6 ecosystem. Unlike GCM, OCB is natively parallelizable in both the encryption and decryption phases: it can process multiple data blocks simultaneously, fully exploiting modern multi-core processors. It requires almost half the clock cycles compared to non-accelerated traditional combinations, making it ideal for encrypting large files on local disks or heavy attachments (common in the post-quantum setting). Historically it was not used due to industrial patents, now released under a free license for open-source use, which paved the way for its standardization in RFC 9580.
EAX
EAX is the third AEAD mode standardized in OpenPGP v6. Built on two CMAC (Cipher-based MAC) passes, EAX is structurally simpler than OCB and does not require parallelizable optimizations to achieve good performance. Its importance lies in the formal proof of security and the online structure: the authentication tag can be verified stream-by-stream without buffering the entire ciphertext, making it suitable for embedded environments and libraries with a minimal cryptographic surface.
The post-quantum PGP synergy
In Post-Quantum PGP these three elements connect directly to the lattice-based algorithms. The ML-KEM key encapsulation protocol establishes a symmetric session key secure against quantum computers. This symmetric key is immediately used by AES-256-OCB or AES-256-GCM to encrypt the message body. Finally, if the user decides to store the PQ private key — composed of thousands of bytes of polynomial vectors and matrices — on the device, it is armored against local brute-force via Argon2id.
NIST SP 800-38F: AES Key Wrap for symmetric keys
The relationship between the OpenPGP v6 / Post-Quantum ecosystem (RFC 9580 / RFC 9980) and the NIST SP 800-38F protocol (AES Key Wrap) focuses on a hyper-specific task: the encapsulation and protection of private symmetric keys within data packets. While AEAD modes (GCM, OCB, EAX) encrypt the message body, the NIST SP 800-38F standard intervenes one step earlier, acting as a security shield for the keys themselves.
The specification defines AES-based Key Wrapping methods (KW and KWP): a form of authenticated encryption specifically designed to protect high-entropy data (other cryptographic keys) rather than text streams. In OpenPGP v6 certificates this protocol is used in combination with Argon2id:
• 1) the user enters the passphrase;
• 2) Argon2id processes the passphrase and derives a symmetric Key Encryption Key (KEK);
• 3) the software uses this KEK to decrypt the actual OpenPGP private key — classical or post-quantum — which is wrapped on disk using AES-KW / AES-KWP.
Why GCM/OCB/EAX are not enough and Key Wrap is needed
Standard AEAD modes require a unique temporary value (nonce) for each operation. If software makes a logical error and reuses the same nonce with the same key (nonce reuse attack), the security of GCM collapses dramatically, exposing the data. The NIST Key Wrap algorithm is instead deterministic and does not require an external nonce: it uses a fixed integrity block (a magic bit string) and applies a strong permutation function (up to 6 crossed AES encryption passes). Even if the same key is encrypted multiple times with the same KEK, there is no loss of security or cryptographic robustness, making it mathematically armored against software implementation errors.
Symmetric quantum resistance
When moving to post-quantum keys, the use of NIST SP 800-38F becomes even more crucial due to the size and structure of the new algorithms. The private keys of ML-KEM or ML-DSA are not simple strings of a few bits, but complex structures composed of polynomial vectors and matrices (up to several kilobytes of data). The Key Wrap implemented in OpenPGP v6 uses AES-256-KW. The use of 256-bit AES guarantees 128-bit symmetric security even against Grover's quantum algorithm — which theoretically halves the effective bits of a symmetric key. This ensures that the “protective box” containing your post-quantum key cannot be broken by a quantum computer via local brute-force attacks on the KEK.
Comparison table: RFC 9580 vs RFC 9980
The following table summarizes the architectural differences between legacy OpenPGP v4 (RFC 4880 and the legacy modes of RFC 9580) and post-quantum OpenPGP v6 (RFC 9980 composite).
Conclusion
Post-Quantum PGP represents the most important paradigm shift in the history of personal and corporate data confidentiality since the 1990s. The transition is not a simple software update, but a complete restructuring of the cryptographic architecture that rests on three fundamental pillars.
Uncompromising security (hybrid approach). The mandatory combination of lattice-based algorithms (ML-KEM and ML-DSA) with classical elliptic curves guarantees total protection. The data remains protected both against tomorrow's quantum computers and against unknown mathematical weaknesses in the new algorithms.
Standard modernization (OpenPGP v6). Native integration with RFC 9580 and the abandonment of obsolete algorithms — such as SHA-1 and v4 keys — close decades of technical debt, introducing more secure fingerprints (SHA-256), mandatory AEAD modes (EAX/OCB/GCM), and Argon2id as a memory-hard KDF for passphrases.
Armored at-rest protection (NIST SP 800-38F). The adoption of the AES-256 Key Wrap protocol ensures that even private keys stored on users' devices are mathematically unassailable, eliminating the risks associated with software errors in the use of initialization vectors (nonces) and resisting the brute force of Grover's quantum algorithm.
Top comments (0)