Why Change Encryption That Already Works?
Much of today’s public-key cryptography relies on mathematical problems that ordinary computers cannot feasibly solve at useful key sizes. A sufficiently large, fault-tolerant quantum computer could use Shor’s algorithm to break the assumptions behind RSA and elliptic-curve systems such as P-256 and X25519. This is a specific weakness in those mathematical constructions, not a machine that instantly guesses every secret. NIST’s introduction explains the reason for replacing them.
The concern begins before that machine exists. An attacker can save encrypted traffic or a database of wrapped keys today and attempt to decrypt it years later: harvest now, decrypt later. A file’s contents might remain commercially or personally sensitive long after its upload. Upgrading future connections cannot erase a copy already collected.
.jpg){kind=link}
Post-quantum cryptography replaces vulnerable public-key mathematics with problems believed to resist both classical and quantum attacks. It is different from quantum key distribution, which uses physical quantum communication equipment. OWL’s post-quantum work is software cryptography.
The Different Types Do Different Jobs
“Post-quantum” describes a security goal, not one algorithm. The distinction that matters most is between establishing a secret and authenticating a statement.
| Type | What it does | Relationship to OWL |
|---|---|---|
| ML-KEM Lattice based | Establishes a shared secret using a public key and an encapsulation message. Derived from CRYSTALS-Kyber; standardized in FIPS 203. | ML-KEM-768 is the post-quantum component in OWL’s hybrid HTTPS and application key-wrap construction. |
| ML-DSA Lattice based | Signs data and verifies signatures. Derived from CRYSTALS-Dilithium; standardized in FIPS 204. | A separate signature technology. ML-KEM support does not mean OWL’s signatures have been upgraded to ML-DSA. |
| SLH-DSA Hash based | Creates signatures using hash-based constructions. Derived from SPHINCS+; standardized in FIPS 205. | Background context, not part of the OWL key-wrap suite described here. |
| AES-256 Symmetric encryption | Encrypts data using an existing secret key. It is not a KEM or a signature algorithm. | Continues to protect content; AES-256-GCM also encrypts and authenticates the small secret inside OWL’s hybrid key envelope. |
A lattice is a mathematical arrangement of points. The actual ML-KEM problem uses high-dimensional, structured arithmetic with deliberately introduced noise. The useful intuition is that authorized participants can establish matching secret material while recovering it from the public information is believed to be hard. A two-dimensional grid is only an analogy, not a security explanation or a recipe for implementing it.
768 is a parameter-set name, not “768-bit encryption.” ML-KEM has three standardized parameter sets: 512, 768 and 1024. ML-KEM-768 is assigned NIST security category 3. That category uses an AES-192 key-search benchmark; it does not certify the entire application or mean “192 bits of quantum security.” See FIPS 203 and NIST’s category definitions.
How Hybrid Keys Work
A key-encapsulation mechanism, or KEM, lets a sender use the recipient’s public key to produce a shared secret and a public encapsulation message. The recipient uses their private key to recover the same secret. A key-derivation function turns it into the keys needed by authenticated encryption. The KEM does not directly encrypt a whole video or document.
A post-quantum/classical hybrid combines ML-KEM with an established elliptic-curve method. The construction is designed to preserve confidentiality if one component remains secure, under its specified assumptions and with a correct implementation. This is not a choice between two fallback modes: both components participate.
“Hybrid” has two meanings
Traditional hybrid encryption combines public-key cryptography with a symmetric cipher, as ECIES does. A post-quantum/classical hybrid combines two public-key methods as well. The word “hybrid” in HPKE’s name does not, by itself, mean the selected algorithms are post-quantum.
What NDEVR OWL Uses
Status checked October 22, 2026. These layers have different algorithms and different rollout states. A successful hybrid HTTPS connection is not evidence that an account’s stored keys have migrated.
1. HTTPS: X25519 + ML-KEM-768
The public ndevr.org endpoint supports the TLS 1.3 group X25519MLKEM768. A compatible client combines X25519 with ML-KEM-768 when establishing the connection’s secret. This protects traffic between that client and the public HTTPS endpoint against passive collection for later decryption. Availability depends on what the client and server actually negotiate. The group is specified in RFC 10024.
TLS key agreement and website authentication are separate. The checked connection used a classical ECDSA certificate signature. Hybrid key agreement does not make that signature post-quantum, and HTTPS alone does not provide end-to-end protection through a service that processes plaintext.
2. Application key wrapping: ML-KEM-768 + P-256
OWL’s implemented application suite is MLKEM768-P256, used with HPKE base mode, HKDF-SHA256 and AES-256-GCM. It wraps small secrets such as content keys for recipients. Its classical component is a separate P-256 key belonging to the hybrid key pair, not the account’s existing signing key.
The implementation follows RFC 9180 for HPKE and pins the construction in PQ HPKE draft 05 and concrete hybrid KEMs draft 03. Those pinned extensions are drafts, not final RFCs. Standardization of ML-KEM does not make OWL’s complete protocol a NIST-validated cryptographic module.
For readers comparing formats: the hybrid public key is 1,249 bytes; the encapsulation is 1,153 bytes. OWL adds a one-byte format marker and a 16-byte GCM tag, so wrapping a 32-byte secret produces 1,202 bytes before text encoding. That overhead is attached to the wrapped secret, not every block of the file.
Implemented does not mean enabled for everyone
At the status check, general account enrollment remained closed and enrollment was limited to controlled test accounts. The production migration to hybrid recipient-key writers and rewrapping of historical keys was not complete. Existing classical ECIES envelopes must not be described as post-quantum protected merely because the server supports the new format.
3. Signatures, passwords and recovery are separate
ML-KEM establishes secrets; it does not authenticate an account identity or sign a sharing request. OWL’s current hybrid-key certificates use classical ECDSA. This page does not claim deployed ML-DSA signatures or quantum-resistant authorization throughout OWL.
OPAQUE handles password authentication and helps derive the key that opens a protected account-key envelope. OWL’s Ristretto255/3DH OPAQUE suite is classical. Adding ML-KEM to recipient key wrapping does not make that login or private-key-unlock construction post-quantum. Password quality, private-key protection and user-held recovery remain independent parts of the security design.
What It Does Not Solve
AES still matters. Quantum key search has a different effect on symmetric encryption from Shor’s attack on RSA and elliptic curves. Grover’s algorithm offers an idealized square-root search speedup; it does not instantly break AES. AES-256 provides substantial margin, but practical attack cost and implementation details matter. NIST’s FAQ discusses why simple “halve the bits” claims do not capture the whole picture.
Old copies remain old copies. Rewrapping a key can protect its new envelope. If an attacker already retained an older vulnerable envelope for that same content key, changing the server’s current copy cannot revoke the attacker’s copy. Changing the content key and re-encrypting data is a separate operation, and cannot erase plaintext already learned.
Identity and devices still matter. A compromised endpoint can read plaintext after decryption. A substituted recipient public key can redirect a secret to an attacker unless the protocol authenticates it. Backups, recovery routes and plaintext-processing modes can expose paths that a stronger recipient envelope does not repair. See Sharing in OWL for how access and copies differ.
Post-quantum does not automatically mean forward secrecy. If a long-lived recipient private key is stolen, the attacker may be able to open previously recorded envelopes addressed to it. Nor does a new algorithm guarantee recovery from an attacker who still controls a device.
For any “post-quantum” claim, ask which operation it protects, which algorithm it uses, whether that protection is enabled for your account and client, and what happens to older data. OWL Encryption explains the broader storage and key-delivery model.
Sources & Further Reading
- NIST: What is Post-Quantum Cryptography? — the threat and migration rationale.
- NIST standards: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA).
- RFC 10024 — hybrid TLS 1.3 key agreement; RFC 9180 — HPKE.
- OWL’s pinned construction references: PQ HPKE draft 05 and concrete hybrid KEMs draft 03. These identify the implemented versions, not a claim that they are the latest revisions.
- NIST PQC FAQ — implementation questions and symmetric-cryptography considerations.
OWL-specific algorithm and format details were checked against its native, browser and CLI implementation; availability was checked against the production configuration and a TLS handshake on the status date above.