DEV Community: Asahina-Aoi

Post-Quantum Pretty Good Privacy (PQ-PGP)

Asahina-Aoi — Thu, 29 Oct 2026 09:42:53 +0000

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.

CryptPix – Steganography (AES-256-GCM + HMAC-SHA-256 + Argon2id + Synch-HILL + STC + Viterbi)

Asahina-Aoi — Tue, 20 Oct 2026 05:27:17 +0000

Try it (WebApp): https://sh3lly.byethost11.com/cryptpix
Technical Report: https://github.com/AoiAsahina/CryptPix/blob/main/CryptPix.pdf

// THE TOOL

CryptPix encrypts your messages with AES-256-GCM + HMAC-SHA-256 (keys derived via memory-hard Argon2id), then embeds the ciphertext through Synch-HILL distortion costs coupled with Syndrome-Trellis Codes (STC) and Viterbi decoding across all three color channels. Payload size is hard-capped at 5% of cover capacity to resist statistical steganalysis. The result looks identical to the original.

// SUPPORTED CARRIERS

CryptPix accepts virtually any image format as the carrier.
✓ Joint Photographic Experts Group .jpeg
✓ Portable Network Graphics .png
✓ Graphics Interchange Format .gif
✓ WebP .webp
✓ AV1 Image File Format .avif
✓ JPEG XL .jxl
✓ Tagged Image File Format .tiff
✓ Bitmap .bmp
✓ Raw / Digital Negative .raw/.dng
✓ HEIC / HEIF .heic/heif

Internally, the encrypted payload is embedded into the pixel raster and re-encoded as lossless PNG, guaranteeing bit-perfect survival of your hidden data.

Browser-native decoding for all common formats
Lossless PNG output preserves every hidden bit
Synch-HILL + STC embedding across R, G, B channels (cost-ordered)

// THE PIPELINE

Encrypt: Your message is encrypted with AES-256-GCM. A unique 256-bit key is derived from your password using Argon2id (memory-hard, 64 MB, 3 iterations) and a fresh random salt — GPU/ASIC resistant.

Package: The encrypted payload is bundled as salt || IV || HMAC tag || length || ciphertext. No magic bytes or version tag are written. A known magic byte would give an adversary a free distinguisher. Tamper detection is provided by the 256-bit HMAC-SHA-256 tag (verified before AES-GCM decryption), with the inner 128-bit AES-GCM tag as a second layer.

Embed: Synch-HILL computes per-pixel distortion costs (Laplacian high-pass + 3×3 averaging). STC with Viterbi decoding then selects minimum-cost LSB flips across R/G/B in cost-ascending order. Payload is capped at 5% of cover capacity to resist chi-square, sample-pairs, weighted-stego, and SRM-class attacks.

Deliver: The encoded image is exported as lossless PNG to preserve every hidden bit. The output looks identical to the original, but carries your secret.

// SECURITY MODEL

Threat model: Synch-HILL + STC minimizes detectable distortion. 5% capacity cap, content-adaptive costs, and 3-channel cost-ordered embedding resist chi-square, sample-pairs, weighted-stego, and SRM-class attacks.

✓ Confidentiality (AES-256-GCM)
✓ Integrity (256-bit HMAC-SHA-256)
✓ Brute-force resistance (Argon2id, 64 MB)
✓ Per-file key uniqueness (16-byte salt)
✓ Steganalysis resistance (STC, 5% cap)

Cryptography that holds up: Every layer of CryptPix uses well-studied primitives from the Web Crypto API. No custom cryptography, no third-party libraries, no telemetry. Everything runs locally in your browser.

AES-256-GCM + HMAC-SHA-256: AES-GCM provides confidentiality with a 128-bit embedded tag. A separate 256-bit HMAC-SHA-256 over iv‖ciphertext raises overall authentication strength to 256 bits and detects any tampering.

Argon2id: Modern key derivation function (PHC winner) resistant to GPU and ASIC brute-force. Each derivation requires 64 MB of memory, making parallel cracking economically impractical.

Unique salt per file: Two encryptions with the same password produce completely different keys. Pre-computed rainbow tables are useless.

96-bit random IV: Every encryption uses a unique initialization vector. Repeating the same message+password never yields the same ciphertext.

Local processing: Your images, messages, and passwords never leave the browser. No server, no upload, no telemetry, everything runs in your tab.

No third-party crypto: All cryptographic operations use the browser’s native, audited Web Crypto implementation. No custom or JavaScript-based crypto libraries.

Synch-HILL + STC: HILL distortion costs (Laplacian high-pass + 3×3 averaging) drive a Syndrome-Trellis-Code with Viterbi decoder, operating on cost-ordered LSBs across R, G, and B. A synchronizing pseudo-random pattern is shared implicitly via cover dimensions. Payload is hard-capped at 5% of cover capacity to resist chi-square, sample-pairs, weighted-stego, and SRM-class statistical attacks.

// OPERATIONAL GUIDANCE

Stay invisible. Use it right: Even the best steganography fails if the cover is compromised in transit. Follow these operational rules to keep your payload truly hidden from steganalysis and forensic inspection.

Defense in depth: Argon2id + AES-256-GCM + HMAC-SHA-256 protect confidentiality; HILL+STC raises the statistical-detection floor. Neither defends against provenance comparison, JPEG-cover forensics, or an adversary who reads the source and trains a matched detector.

Never re-encode as JPEG: WhatsApp, Telegram, Discord, social media, and most email clients re-compress images as JPEG by default. This destroys every LSB and your payload is gone. Only transmit the PNG via lossless channels: Signal "as document", email attachments sent as files, direct file transfer, or upload to a file host.

Use natively-lossless covers: JPEG-sourced covers (including picsum.photos samples) carry residual DCT block signatures exploitable by JPEG-compatibility steganalysis (JRM, J-UNIWARD-aware detectors). Prefer PNG screenshots, camera RAW exported to PNG, vector drawings rasterized to PNG, or images you generated locally.

Never reuse a cover: If an adversary obtains the original cover (from your camera roll, social media history, or by guessing the picsum seed), a pixel-diff comparison reveals every modified LSB, defeating all steganographic protection regardless of algorithm. Each cover image must be used exactly once and never published in its original form.

Use strong, unique passwords: Argon2id raises brute-force cost to ~64 MB of memory per attempt, but a dictionary password is still crackable. Use 20+ character random passwords (the Generate button creates 32-char ones). Never reuse a password across multiple stego images, if one is broken, all are.

Use private browsing: Browser cache, swap, and indexedDB may retain plaintext or intermediate buffers after use. For sensitive work, use private/incognito mode and close the tab when done. Clear browser cache periodically if you use CryptPix regularly.

Keep payloads small: The 5% capacity cap is a hard upper bound, but smaller is always better. A 1 KB text message in a 1 MP image is far harder to detect than a 50 KB file at the cap. Prefer text over binary files when possible, and split large payloads across multiple cover images.

// ALTERNATIVE METHODOLOGY

If you prefer an approach other than steganography (which involves hiding the very existence of a message), the primary and most secure alternative is cryptography, which instead aims to make the message completely unintelligible to anyone other than the authorized recipient.

Try it (WebApp): https://sh3lly.byethost11.com/0x8
Technical Report: https://github.com/AoiAsahina/0x8/blob/main/0x8.pdf

0x8 Post-Quantum Cryptographic Suite

Asahina-Aoi — Thu, 08 Oct 2026 08:18:33 +0000

Greeting everyone,
I would like to share a web app I recently developed, and I would really appreciate hearing your opinions, feedback, or any security issues you might encounter.

Thanks for your time, and have a great day ahead!

The system offers "Encrypt-then-Sign" hybrid encryption for Video Call, Screen Sharing, Chat, File Transfer for real-time communications.
Implementing NIST-standardized algorithms at the highest security level:

ML-KEM-1024 (FIPS 203) • Kyber-1024
ML-DSA-87 (FIPS 204) • Dilithium-87
SLH-DSA-256 (FIPS 205) • Sphincs+
FN-DSA-1024 (FIPS 206) • Falcon (*)

(*) Algorithm is in the process of final standardization by NIST.

https://github.com/AoiAsahina/0x8

Motivation

The transition to post-quantum cryptography (PQC) demands not only standardized algorithms but also practical, deployable systems that integrate PQC primitives into existing communication infrastructures. The “Store-Now-Decrypt-Later” (SNDL) threat makes classical key agreement (ECDH) insufficient: an adversary recording ciphertexts today can decrypt them once a cryptographically relevant quantum computer emerges. Browser-based deployment offers zero install accessibility but introduces unique challenges in trust establishment, key management, and real-time encryption.

Encrypt + Sign

1.The sender uses the recipient's ML-KEM public key to encapsulate a fresh shared secret. This operation produces two outputs: the shared secret itself and a KEM ciphertext that encodes it. Only the holder of the corresponding private key can later recover the shared secret from this ciphertext.

2.A current Unix timestamp and a 16-byte random nonce (bound into the AAD for uniqueness) are generated. Together with the protocol version byte, the signature algorithm identifier, the KEM ciphertext, and the byte lengths of all subsequent fields (IV, ciphertext, signature), they will form part of the Additional Authenticated Data (AAD). To ensure complete cryptographic binding, the digital signature itself is also included in the AAD. This guarantees that any tampering with the signature or ciphertext is detected during decryption.

3.An AES-256-GCM encryption key is deterministically derived from the shared secret using HKDF-SHA256. The KEM ciphertext serves as the salt (ensuring uniqueness per encapsulation) and a fixed info string identifies the protocol context, preventing key reuse across different applications.

4.The sender signs the concatenation of the plaintext and the KEM ciphertext using their own digital signature private key (DSA). This proves authorship and ensures integrity. The generated signature bytes are then added to the AAD, indissolubly linking the signature's integrity to the encrypted payload.

5.The plaintext is encrypted with AES-256-GCM using the derived key, the random nonce, and the full AAD (which now includes the component lengths and the digital signature). AES-GCM provides both confidentiality and authenticity: if any byte of the AAD or ciphertext is altered, decryption will fail outright.

6.Everything is assembled into a single binary packet with a fixed header structure: the PQENC magic bytes, protocol version, signature algorithm ID, timestamp, nonce, then length-prefixed KEM ciphertext, initialization vector, encrypted ciphertext, and digital signature. This format allows the receiver to parse each field unambiguously.

Decrypt + Verify

1.The encrypted binary packet is parsed by reading the PQENC magic header, protocol version, signature algorithm identifier, timestamp, nonce, and then extracting each variable-length field (KEM ciphertext, initialization vector, encrypted ciphertext, digital signature) using the stored length prefixes to locate boundaries precisely.

2.Basic sanity checks are performed: the KEM ciphertext length must be exactly 1568 bytes (as required by ML-KEM-1024), the IV must be exactly 12 bytes (as required by AES-256-GCM), and the embedded timestamp is compared to the current time. If the skew exceeds 180 seconds in either direction, or if lengths are tampered with, the message is rejected as expired, replayed, or malformed.

3.The recipient uses their ML-KEM private key to decapsulate the KEM ciphertext, recovering exactly the same shared secret that the sender obtained during encapsulation. This is the core post-quantum key agreement step.

4.The same AES-256-GCM key is re-derived from the shared secret using HKDF-SHA256, with the identical salt (KEM ciphertext) and info string. Because HKDF is deterministic, both parties arrive at the same key independently.

5.The AAD is reconstructed from the version, algorithm ID, timestamp, nonce, KEM ciphertext, component lengths, and crucially, the digital signature. AES-256-GCM decryption then verifies the authentication tag against this AAD and the ciphertext. This ensures the signature itself was not tampered with in transit. If any byte was modified, the tag check fails and decryption is rejected without revealing any plaintext.

6.Finally, the digital signature is verified against the concatenation of the recovered plaintext and the KEM ciphertext, using the sender's public key. A valid signature confirms that the message was genuinely signed by the claimed sender and that neither the plaintext nor the KEM ciphertext was tampered with in transit.

PQC Encryption OFF
By default, chat and file transfers rely on WebRTC's built-in DTLS (classical, vulnerable to Store-Now-Decrypt-Later).

PQC Encryption ON (Chat and File Transfer)
Add a post-quantum AES-256-GCM layer on top of the DataChannel (chat and file), using session keys derived from ML-KEM encapsulation with the peer's verified FIPS public key. Received file names are automatically sanitized to prevent path traversal attacks.

PQC Encryption ON (Video Call and Screen Sharing)
Real-time media streams use WebRTC Insertable Streams to apply PQC encryption directly on the RTP frames. To ensure zero-latency ratcheting, the Web Worker autonomously advances the AES-256-GCM key every 3 seconds via HKDF, without needing to communicate with the main thread. A clear-text Ratchet ID is prepended to each encrypted frame so the receiver can re-sync its key state in case of packet loss. Any frame that fails cryptographic validation is silently dropped to prevent data leaks.

Stream-to-Disk Transfer (Chat and File Transfer)
If your browser supports File System Access API, click the "Save" button in the chat to stream data directly to your hard drive in real-time. Maximum File Size 2 TB (2,199,023,255,552 bytes)

Stream-to-RAM Transfer (Chat e File Transfer)
If your browser doesn't supports File System Access API, will buffer in RAM and offer a download link in the chat upon completion. Maximum File Size 2 GB (2,147,483,648 bytes)

Quantum-Safe Key Verification
To prevent Man-in-the-Middle attacks on WebRTC signaling, verify your peer's FIPS identity using an Out-of-Band channel (e.g., read the code over a phone call).

VERIFY AUTHENTICATION CODE
WebRTC uses classical DTLS (ECDH) which is vulnerable to Store-Now-Decrypt-Later quantum attacks. If a quantum attacker intercepts the signaling server today, they could substitute FIPS keys. Verifying the SAS ensures the keys you received are authentic, creating a true Post-Quantum secure channel.

PQ Handshake

1.Commit phase: Each peer generates a random 32-byte salt, then computes a SHA-256 hash of the salt combined with their own KEM public key, DSA public key, and signature algorithm identifier. This hash is sent to the other peer as a cryptographic commitment, without revealing the actual keys yet. This prevents a malicious signaling server from adaptively choosing keys based on what the other party sends.

2.Reveal phase: Once both commitments have been exchanged, each peer sends their actual KEM public key, DSA public key, salt, and algorithm identifier, along with a Proof-of-Possession (PoP) signature. The PoP is a digital signature over the concatenation of both public keys, the salt, and the algorithm ID, proving that the sender actually holds the corresponding DSA private key.

3.Commitment verification: Each peer recomputes the SHA-256 hash of the received keys, salt, and algorithm ID, then checks that it matches the commitment they received earlier. A mismatch indicates a potential man-in-the-middle attack. The PoP signature is also verified to confirm that the peer genuinely owns the DSA key they claim to have.

4.SAS computation: Both peers compute a Short Authentication String (SAS) by hashing a deterministically sorted JSON object containing both peers IDs, KEM public keys, DSA public keys, and algorithm identifiers with SHA-256. The first 16 hexadecimal characters of the digest form the SAS code. Because the input is sorted, both peers produce the same SAS independently.

5.Out-of-band verification: The SAS must be compared through a separate, trusted channel, for example by reading it aloud over a phone call. If both peers see the same code, they can be confident that no man-in-the-middle attack has altered the keys during the WebRTC signaling exchange.

6.Trust establishment: Once the SAS is verified, the peer keys are locked as trusted. The Encrypt and Decrypt tabs are automatically populated with the peer KEM public key, DSA public key, and the correct signature algorithm identifier, so subsequent encrypted communication uses the authenticated keys.

7.Optional PQC session encryption: If enabled, the initiator performs ML-KEM encapsulation with the peer verified public key and sends the resulting KEM ciphertext over the DataChannel. The responder decapsulates it with their private key. Both peers then derive an AES-256-GCM session key via HKDF-SHA256 (shared secret as input key material, KEM ciphertext as salt, protocol info string). The responder sends an acknowledgment to confirm the channel is ready. Forward Secrecy is provided via automatic key ratcheting: every sent message or file chunk derives a fresh AES-256-GCM key using HKDF-SHA256 from the previous key, so compromising the current key cannot decrypt past messages. Separate send/receive ratchet keys prevent desync during simultaneous communication. A ratchet counter is included in each encrypted payload. To mitigate packet loss causing permanent desync, the receiver automatically fast-forwards its ratchet state if a gap is detected, while strictly rejecting any rollback attempts (receiving an older counter) to prevent tampering.

Binary Container Format
The PQENC format encodes all cryptographic artifacts into a single binary packet with a fixed header structure and length-prefixed variable fields

Additional Authenticated Data (AAD) Construction
The AAD binds all metadata and the signature itself into the AES-GCM authentication tag, ensuring that any modification to any field is detected.

The digital signature is included in the AAD. This creates a bidirectional integrity binding:
• AES-GCM authentication ensures the signature was not modified in transit.
• The DSA signature covers (plaintext∥KEM ciphertext), ensuring message authenticity.
• Modifying either the signature or the ciphertext causes AES-GCM tag verification to fail, preventing selective tampering.

PQENC Encryption Security Properties

Confidentiality > AES-256-GCM encryption with ML-KEM-derived key
Authenticity > AES-GCM authentication tag + DSA signature
Integrity > AAD binds all metadata + signature into GCM tag
Non-repudiation > DSA signature on (plaintext || KEM ciphertext)
Replay resistance > Timestamp validation (±180 seconds)
Key uniqueness > HKDF with KEM ciphertext as salt
Algorithm agility > SigAlgoId field supports 6 signature algorithms

Sign-then-Encrypt: The PQENC protocol uses Sign-then-Encrypt (sign the plaintext, then encrypt it), but with a critical enhancement: the signature is also included in the AAD of the encryption. This means:
• The signature is authenticated by AES-GCM (any modification to the signature in transit is detected).
• The signature covers the plaintext and KEM ciphertext (proving authorship and integrity of the plaintext).
• The KEM ciphertext in the signed data provides binding between the encryption key and the signer’s claim.

Why include the signature in AAD? Without this binding, an attacker who compromises the recipient’s KEM private key could:

Decrypt the ciphertext.
Replace the original signature with their own (re-signing the plaintext).
The recipient would not detect this substitution. By including the signature in the AAD, any modification to the signature causes AES-GCM tag verification to fail, creating an indissoluble link between the signature’s integrity and the encrypted payload.

Handshake Security Properties

Commit-reveal prevents adaptive MITM: In a standard key exchange, a malicious signaling server could wait for Alice to send her public key, then send a different key to Bob (and vice versa). The commit-reveal protocol forces the adversary to commit to a key before seeing the other party’s key, making adaptive key selection impossible.

PoP prevents key injection: Even if an adversary obtains a valid DSA public key, they cannot produce a valid PoP signature without the corresponding private key. This prevents an attacker from claiming ownership of a key they don’t control.

MITM resistance > Commit-reveal prevents adaptive key substitution
Key ownership proof > Proof-of-Possession (PoP) signature
Out-of-band verification > SAS comparison via trusted channel
Signaling server independence > PQ handshake operates over DataChannel after WebRTC establishment.

Session Encryption Security Properties

Forward secrecy > KDF ratchet (one-way key derivation)
Post-compromise security > PQC re-keying via fresh ML-KEM encapsulation
Rollback resistance > Counter comparison with rejection of older values
Domain separation > Separate send/receive ratchet chains
Message authentication >AES-GCM with counter-based AAD

Forward secrecy analysis: Each ratchet step applies HKDF-SHA-256 to derive the next key. Since HKDF is a one-way function, knowing Kn does not allow computation of Kn−1. An adversary who compromises a ratchet key cannot decrypt past messages.

Re-keying provides post-compromise security: If an adversary compromises the current ratchet state, they can only decrypt future messages until the next PQC re-key. The re-key uses a fresh ML-KEM encapsulation, which is quantum-safe, establishing a completely new key tree.

Key Regeneration and Handshake Reset
If a key pair is regenerated while a P2P connection is active and a PQ handshake has been performed (or is in progress), the system:
• Aborts any in-progress file transfers.
• Sends a pq-handshake-reset message to the peer.
• Resets the local handshake state (commitments, peer keys, SAS, trust status).
• Disables the PQC session encryption layer.
This prevents key confusion attacks where stale keys could be used after regeneration.

Keyboard Shortcuts

Ctrl+1 Switch to Key Generation
Ctrl+2 Switch to Encrypt + Sign
Ctrl+3 Switch to Decrypt + Verify
Ctrl+4 Switch to WebRTC P2P
Ctrl+5 Switch to PQ Handshake
Ctrl+6 Switch to Video Call
Enter Send chat message

References

[1] National Institute of Standards and Technology. FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard. 2024.

[2] National Institute of Standards and Technology. FIPS 204: Module-Lattice-Based Digital Signature Standard. 2024.

[3] National Institute of Standards and Technology. FIPS 205: Stateless Hash-Based Digital Signature Standard. 2024.

[4] National Institute of Standards and Technology. FIPS 206: Fast-Fourier Lattice-Based Compact Signature over NTRU Standard. 2024.

[5] Krawczyk, H. Cryptographic Extraction and Key Derivation: The HKDF Scheme. CRYPTO 2010.

[6] Dworkin, M. Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM). NIST SP 800-38D, 2007.

[7] Perrig, A., Song, D. Hash Visualization: A New Technique to Improve Real-World Security. International Workshop on Cryptographic Techniques and E-Commerce, 1999. (SAS concept)

[8] Vaudenay, S. Secure Communications over Insecure Channels Based on Short Authenticated Strings. CRYPTO 2005.

[9] Marlinspike, M. The Double Ratchet Algorithm. Open Whisper Systems, 2016.

[10] Paul Miller, @noble/cryptography. noble-post-quantum: ML-KEM, ML-DSA, SLH-DSA, FN-DSA for JavaScript