Why Use Post-Quantum Encryption?
Much of today’s public-key cryptography relies on mathematical problems that ordinary computers cannot solve in any practical time at the key sizes in use. Quantum computers work differently. They are not simply faster ordinary computers, but for a few specific kinds of problem they can take shortcuts that ordinary computers cannot. Two of those problems, factoring very large numbers and a related problem on elliptic curves, are the ones behind the methods most websites and apps use to protect connections and share encryption keys. A large and reliable enough quantum computer could solve them, which would undo that protection. This is a specific weakness in those mathematical constructions, not a machine that instantly guesses every secret. NIST’s introduction explains the risk in more detail. For how such a machine works, and how it finds those shortcuts, start with What is a Quantum Computer?, the first article in a five-part series.
The risk begins when vulnerable encrypted data is collected, even if decryption remains years away. An adversary can record encrypted communications and the relevant key-exchange information, retain them, and attempt to recover the keys with a sufficiently capable future quantum computer. This is called harvest now, decrypt later. It also applies to stolen content-key envelopes protected by quantum-vulnerable public-key cryptography; it does not mean every form of encrypted storage is equally vulnerable.
There is an explicit official assessment that collection is already happening. On October 1, 2026, NSA stated that adversaries are already employing this strategy. Its public announcement does not identify particular operations or disclose the underlying intelligence. An October 2026 GAO report documents historical routing manipulation and other collection techniques that could support harvesting, but those examples do not establish quantum-related intent. These are strong grounds for treating the threat seriously, with a distinction between an official assessment and independently verifiable evidence of a specific operation.
Your data can remain sensitive for years: contracts, medical records and business plans. Upgrading encryption later cannot retroactively protect a copy already held by an adversary. NIST’s October 27, 2026 guidance identifies this risk as a reason to migrate before a cryptographically relevant quantum computer exists. Several cloud providers already deploy post-quantum protections or publish migration plans; the useful question is which layer they protect. Our cloud-platform comparison distinguishes network encryption, file-key protection and availability, including OWL’s coverage at launch.
.jpg){kind=link}
Post-quantum cryptography builds public-key methods on different mathematical problems, ones believed to resist both classical and quantum attacks. It is not quantum key distribution, which needs dedicated physical quantum-communication hardware. OWL’s post-quantum protection is ordinary software cryptography.
Post-Quantum Encryption Explained
1. Start with a lattice
A lattice is a repeating arrangement of points. Imagine this mesh continuing in every direction. We use a small three-dimensional picture here; the real encryption works with much larger mathematical structures.
In the real algorithm
ML-KEM uses public matrices of polynomials and fixed modular arithmetic; the public matrix is not literally the three-direction basis drawn here. This mesh is a teaching aid; encryption does not place your file at a point in a visible grid.
2. Add a little noise
Noise means small, deliberate errors added to a calculation’s results. Here the dots shift slightly to show them. Next, this noisy calculation produces two related bundles of numbers, one step at a time.
Why the noise matters
A simplified public-key relation is t = A·s + e: A is public, s is secret, and e is a small error. In ML-KEM these are structured polynomial objects. The real problem is Module Learning with Errors, not finding the nearest dot in this drawing.
3. Meet the public calculation rules
Our toy example has three public calculation rules: A, B and C. Each gives the direction and size of one addition. Watch the matching lattice edges light up. Combining whole numbers of these additions gives the lattice points. Everyone can know the rules; the next step chooses secret counts.
What do the three numbers in each rule mean?
They say how much one addition changes each coordinate. A = (2, 1, 0) adds 2 to the first coordinate, 1 to the second and 0 to the third. The illustration spreads the directions apart so we can see them. These tiny vectors explain the idea; real ML-KEM uses public polynomial matrices and modular arithmetic.
4. Choose a secret bundle of numbers
Your device randomly chooses a secret bundle of numbers. In our example, they are the counts: 7 additions of A, 2 of B and 9 of C. The public rules say what to add; these private numbers say how many times. Your device keeps the counts secret.
Are these my password?
No. These numbers are generated by the device, not chosen by you or taken from your password. The short numbers in this picture are made up; actual ML-KEM uses larger structured collections.
5. Follow the calculation path
Start at zero. Each lit edge means add one direction. First come 7 additions of A. Then 2 of B. Then 9 of C. This calculation path ends exactly on a point of the lattice. A small error then nudges the result just off it.
How does a path become a calculation?
Adding the same direction repeatedly is multiplication. In this small example, A = (2, 1, 0), B = (3, 0, 1), and C = (1, 2, 1). So 7A + 2B + 9C = (29, 25, 11). The paths show those additions; their order does not change the endpoint. The illustration spaces the three directions apart to make the depth visible; the counts and arithmetic stay the same. The next slide follows the first coordinate, 29, as noise changes it to 30. Real ML-KEM uses much larger polynomial structures and modular arithmetic. This small, easily reversible example explains the geometry; it does not demonstrate the algorithm’s security.
6. Calculate a second bundle
Now follow just the first coordinate of that path. Rule A contributes 2 per addition, Rule B 3 and Rule C 1, each multiplied by its secret count. Adding 14 + 6 + 9 gives 29. A small error of +1 makes it 30. The noisy result is saved, and the secret numbers are kept too.
How does this relate to the real calculation?
This shows one output of a tiny multiply-and-add example. The public calculation rules provide further multipliers for the other outputs in the result bundle. ML-KEM uses vectors and matrices of polynomials, arithmetic modulo a fixed number, and carefully sampled errors. Its structure gives rise to the lattice problem illustrated by the mesh. The small example here is not secure encryption; it explains the roles of secret inputs, public calculation rules and noise.
7. Give the bundles their names
The original secret numbers form part of the private key. The noisy results, packaged with the public calculation rules, form the public key. A “key” is just stored numbers with a cryptographic job. The public key is the bundle someone else uses in the next step.
What else is stored?
The private key also keeps information needed to check incoming messages. The public numbers behind the public calculation rules are represented compactly by a seed. Neither key is a dot or an image of the mesh; the mesh is our picture of the underlying mathematics.
8. Use the public key to protect a new value
The sender starts with the recipient’s public key. It adds a fresh random value. From those two it calculates Secret A and keeps it. New noisy lattice sums hide the random value in a protected message. Only that message is sent.
Where does “encapsulation” fit?
Encapsulation is the name for this whole operation. ML-KEM derives the shared secret and encryption randomness from a fresh random value and the public key. Its encryption step makes new noisy combinations using the public calculation rules and noisy results and encodes the random value into the resulting ciphertext. The diagram shows the two jobs separately: key derivation produces Secret A; lattice-based encryption protects the random value. This is a new exchange, not a repeat of the earlier key-generation example. OWL also establishes the P-256 contribution shown in step 11.
9. The recipient recovers the same secret
The protected message reaches the recipient. The secret numbers in its private key cancel a matching calculation in the message. Rounding past the leftover noise recovers the sender’s random value. After checking the message, the recipient calculates the same Secret A. Neither Secret A nor the private key was ever sent.
What does “decapsulation” mean?
Decapsulation is this recovery-and-checking operation. ML-KEM checks the encapsulation internally and uses an implicit-rejection mechanism for invalid ciphertexts. In OWL, the subsequent authenticated envelope must also verify before its content key is accepted.
10. See the matching lattice terms cancel
Here is that cancellation up close, with tiny numbers. The sender’s total, 128, hides a main term of 24, noise of 4 and the encoded value 100. The recipient multiplies message part 9 by its private number 3: 27, the same main term 24 plus noise 3. Both main terms match because both sides used the same public rules. Subtracting cancels the 24s exactly. The noise leaves 4 − 3 = 1, so 100 + 1 remains. 101 is closest to 100, which decodes to bit 1.
Where do these toy numbers come from?
This new scalar example uses the public multiplier 4 as its public calculation rules, private number 3 and key-generation error 1, so the public result is 4 × 3 + 1 = 13. The sender uses a fresh secret multiplier 2 and encodes one bit as 100 (the other code value is 0). Its two message parts are 4 × 2 + 1 = 9 and 13 × 2 + 2 + 100 = 128. The recipient computes 3 × 9 = 27 and subtracts: 128 − 27 = 101, near 100.
Why does it work? The sender’s main term is (4 × 3) × 2 = 24; the recipient’s is 3 × (4 × 2) = 24. The sender uses the public result 13, not the private 3. The colored blocks expose the hidden decomposition for teaching; the message contains totals, not separately labeled pieces.
Actual ML-KEM uses polynomial vectors and matrices modulo 3329, with compression and a different bit encoding. In simplified notation, public t = As + e; the message contains u ≈ Aᵀy + e₁ and v ≈ tᵀy + e₂ + encoded bits. Subtracting sᵀu from v cancels the common sᵀAᵀy term, leaving the encoded bits and small errors. This is arithmetic using the lattice-based construction, not a search for a dot in this picture. The tiny numbers here provide no security. See FIPS 203, §5.3.
11. OWL combines two kinds of protection
The lattice exchange gave both devices Secret A. A separate classical P-256 exchange gives them matching copies of Secret B. Each device combines A and B the same way. Matching inputs give matching wrapping keys, calculated locally and never sent.
Why combine them?
The hybrid KEM combines the two contributions, then HPKE derives the wrapping key. The P-256 exchange is summarized here rather than animated in full. The construction is designed to keep confidentiality as long as either component remains secure, under its stated assumptions. The P-256 key used here belongs to the hybrid key pair; it is separate from the account’s signing key.
12. Protect the key, then open the file
There are two keys. The green content key encrypts the file. The recipient will need that key to open it. The amber wrapping key seals the content key in an authenticated envelope. The encrypted file and envelope travel to the recipient; the bare content key does not. The recipient’s matching wrapping key verifies and opens the envelope. Verification passed, so it accepts the content key. That key opens the file.
Why this is efficient
The large post-quantum encapsulation travels once, with the key envelope, not with every block of the file. The recipient rejects an envelope whose authentication tag fails, rather than using an unverified content key.
The mesh is a visual analogy, not a simulation of ML-KEM. Algorithm details: FIPS 203; key derivation and envelopes: HPKE (RFC 9180).
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 both OWL’s hybrid HTTPS and its application key wrapping. |
| ML-DSA Lattice based | Signs data and verifies signatures. Derived from CRYSTALS-Dilithium; standardized in FIPS 204. | A separate signature algorithm. OWL’s use of ML-KEM does not make its signatures ML-DSA. |
| SLH-DSA Hash based | Creates signatures using hash-based constructions. Derived from SPHINCS+; standardized in FIPS 205. | Included for 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. | Protects content; AES-256-GCM also encrypts and authenticates the small secret inside OWL’s hybrid key envelope. |
A lattice is a regular arrangement of points. The real ML-KEM problem lives in high-dimensional, structured arithmetic with deliberately added noise. The useful intuition is this: the authorized parties can arrive at matching secret material, while recovering that material from the public information alone is believed to be hard. A two-dimensional grid is only an analogy. It is neither a security argument nor a recipe for implementation.
768 is a parameter-set name, not “768-bit encryption.” ML-KEM has three standardized parameter sets: 512, 768 and 1024. NIST places ML-KEM-768 in security category 3, which is benchmarked against searching for an AES-192 key. The category rates the algorithm, not the whole application, and it does not 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 recovers the same secret with their private key. A key-derivation function then turns that secret into the keys that authenticated encryption needs. The KEM itself never encrypts a whole video or document.
A post-quantum/classical hybrid combines ML-KEM with an established elliptic-curve method. It is designed to preserve confidentiality as long as either component remains secure, given its stated assumptions and a correct implementation. This is not a fallback from one mode to another: both components contribute to every key.
“Hybrid” has two meanings
Traditional hybrid encryption pairs public-key cryptography with a symmetric cipher, as ECIES does. A post-quantum/classical hybrid is a different pairing: two public-key methods. The “hybrid” in HPKE’s name is the first kind, so it does not by itself mean the chosen algorithms are post-quantum.
What NDEVR OWL Uses
OWL uses post-quantum encryption at two layers. Hybrid HTTPS protects connections, while application key wrapping protects the encryption keys delivered to recipients.
Coverage at launch: all OWL accounts will have post-quantum key protection. Profiles upgrade automatically with the product update, and existing content keys will be wrapped with the hybrid construction by launch day. This is NDEVR’s release commitment; pre-release enrollment stages do not describe the released product. Rewrapping protects the updated key envelopes, but cannot change copies an adversary already collected. See the comparison’s OWL launch scope.
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 the traffic between that client and the endpoint against being recorded now and decrypted later. Whether a given connection gets it 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 authenticated the site with a classical ECDSA certificate signature, and hybrid key agreement does not make that signature post-quantum. HTTPS alone is also not end-to-end protection: it ends at any service that handles the plaintext.
2. Application key wrapping: ML-KEM-768 + P-256
OWL uses MLKEM768-P256 with HPKE base mode, HKDF-SHA256 and AES-256-GCM to wrap 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 signing key.
The implementation follows RFC 9180 for HPKE and pins the hybrid construction to PQ HPKE draft 05 and concrete hybrid KEMs draft 03. Both are drafts, not final RFCs. ML-KEM being a NIST standard 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 paid once per wrapped secret, not once per block of the file.
3. Signatures, passwords and recovery are separate
ML-KEM establishes secrets. It does not prove who an account is or sign a sharing request. OWL’s hybrid-key certificates use classical ECDSA signatures, not ML-DSA, so its post-quantum protection covers how keys are established, not who authorizes an action.
OPAQUE handles password authentication and helps derive the key that opens a protected account-key envelope. OWL’s Ristretto255/3DH OPAQUE suite is classical. Using ML-KEM for recipient key wrapping does not make login or private-key unlocking 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 computers affect symmetric encryption far less than they affect RSA and elliptic curves. Grover’s algorithm offers, in theory, a square-root speedup on key search; it does not break AES outright. AES-256 keeps a large margin, though real attack cost and implementation details still matter. NIST’s FAQ discusses why simple “halve the bits” claims do not capture the whole picture.
Identity and devices still matter. A compromised device reads the plaintext after decryption, whatever the algorithm. If an attacker can substitute their own recipient public key, the secret goes to them unless the protocol authenticates that key. Backups, recovery routes and plaintext-processing modes are separate paths that a stronger recipient envelope does not close. 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 thief may be able to open previously recorded envelopes addressed to it. And no new algorithm removes an attacker who still controls the device.
For any “post-quantum” claim, ask which operation it protects, which algorithm it uses, and what happens to older data. OWL Encryption explains the broader storage and key-delivery model.
Sources & Further Reading
- NSA, October 1, 2026 — official assertion of ongoing harvest-now-decrypt-later activity; GAO-27-108740, Table 2 — collection techniques and their evidentiary limits.
- NIST, October 27, 2026 — migration guidance and the urgency of protecting long-lived secrets.
- 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 name the versions OWL implements, which may not be the latest revisions.
- NIST PQC FAQ — implementation questions and symmetric-cryptography considerations.
OWL-specific algorithm and format details were checked against OWL’s native, browser and CLI implementations. The TLS details reflect a handshake checked on October 22, 2026.