DEV Community: Alex

Post-Quantum Crypto Meets a Non-Extractable TPM Key

Alex — Fri, 25 Sep 2026 13:14:02 +0000

Post-Quantum Crypto Meets a Non-Extractable TPM Key

An engineering story about combining two useful properties without pretending either one solves the whole problem.

I ran into an interesting design problem while working on device-bound encryption.

I wanted two things at once:

a key-establishment path designed to withstand future quantum-capable attackers;
a device identity whose private P-256 key stays inside the machine's TPM.

Each goal has a familiar tool. Getting both into one key-establishment flow is where the details start to matter.

The part the TPM already did well

On Windows, the Microsoft Platform Crypto Provider can use a TPM for cryptographic operations. With a suitable key configuration, an application can ask the provider to perform an operation without exporting the private key material into the application.

For an ECDH P-256 key, the rough idea is:

                 Windows application
                         |
                  request ECDH
                         |
                         v
                 Platform Crypto Provider
                         |
                         v
                 TPM-held P-256 key
                         |
                         v
                  shared secret bytes

The application works with a key handle and an operation result. It does not need to copy the private scalar out of the TPM.

That is useful for device binding. Copying the application's files to another machine does not, by itself, copy the TPM-held private key too.

But P-256 is classical elliptic-curve cryptography. A sufficiently capable quantum computer would change the assumptions behind it. I wanted a post-quantum component in the design as well.

ML-KEM brought a different strength

NIST standardized ML-KEM in FIPS 203. ML-KEM-768 lets one party encapsulate a shared secret to a public key; the other party decapsulates it with the corresponding private key.

Sender                                      Recipient
------                                      ---------
ML-KEM public key                           ML-KEM private key
       |                                           |
 encapsulate                                  decapsulate
       |                                           |
       +-- ciphertext ----------------------------+
       +-- shared secret --------------------------+

That gives the design a post-quantum component. It does not make the ML-KEM private key hardware-bound: in this design, that private component is still managed by software and can be copied if the machine or process exposes it.

So the two mechanisms had complementary properties:

Component	Intended contribution	Where the private component lives
ML-KEM-768	Post-quantum key establishment	Software-managed key material
P-256 ECDH	Device-bound classical contribution	TPM-backed key handle and operation

I wanted both contributions to matter to the final shared secret.

Why two independent recovery slots are not a hybrid

A tempting design is to wrap the same content key twice: once for ML-KEM and once for P-256, then let either path recover it.

                         +-- ML-KEM path --+
Encrypted content key --|                 |--> recovered key
                         +-- P-256 path ---+

That is two alternative ways in. If either path is enough on its own, the overall result can be limited by whichever path is easier to defeat. It does not require an attacker to break both components.

The design I wanted instead has both components feed one hybrid key-establishment construction:

ML-KEM decapsulation ---- shared secret A --+
                                             +--> specified hybrid KDF --> final secret
TPM ECDH operation ------- shared secret B --+

This is the point where I did not want to invent a combiner from intuition. A line such as hash(secret_a || secret_b) looks simple, but a secure construction also has to define input ordering, labels, transcript binding, failure behavior, and the security model.

The concrete MLKEM768-P256 construction in the CFRG hybrid-KEM draft specifies how these pieces fit together. It uses ML-KEM-768 and P-256 with a defined combiner and domain-separation label. The draft's current wire sizes are 1,249 bytes for the encapsulation key and 1,153 bytes for the ciphertext.

Those are larger than a plain P-256 exchange. For a file-encryption envelope, the extra bytes are usually less important than getting the composition right.

Keeping the P-256 operation inside the TPM

The implementation challenge was to preserve the TPM boundary while following the hybrid construction.

Conceptually, the recipient side looks like this:

// Simplified pseudocode, not a drop-in implementation.
let pq_secret = mlkem768_decapsulate(
    &mlkem_private_key,
    &mlkem_ciphertext,
)?;

let p256_secret = platform_provider.ecdh(
    tpm_key_handle,
    &ephemeral_p256_public_key,
)?;

let final_secret = specified_hybrid_kem_combine(
    pq_secret,
    p256_secret,
    &encapsulation_context,
)?;

The exact inputs and encoding must come from the selected specification and implementation. The architectural boundary is the useful part to see: software handles the ML-KEM operation; the platform provider asks the TPM to do ECDH; the hybrid construction consumes both results.

There is no step that exports the TPM's P-256 private scalar. The TPM returns the result of an operation, not the key itself.

The keys need independent origins

A hybrid design can quietly lose its point if one private component is derived from the other.

For example, deriving an ML-KEM key from the P-256 secret might look convenient:

P-256 secret --> KDF --> ML-KEM private key

But then a failure that exposes the classical secret could also expose the post-quantum key derived from it. Two algorithms would not mean two independent failure domains.

The key material should be generated independently, with the right randomness and key-generation procedure for each component:

independent random input --> ML-KEM key pair
TPM key generation       --> P-256 key pair

The exact lifecycle, backup, and recovery rules still need to be designed for the product. Independence at key generation is one necessary piece, not a complete lifecycle policy.

What “hybrid” does and does not promise

It is easy to summarize a hybrid as “if one algorithm breaks, we're safe.” That is too broad without assumptions.

The intended benefit is that recovering the final secret should require defeating the specified hybrid construction, rather than merely finding either of two independent unwrap paths. The exact claim depends on the construction, correct implementation, key independence, and the attacker's access to both components over time.

For example, if an attacker copies the software ML-KEM private key today and P-256 becomes breakable later, the two events can combine.

A TPM boundary raises the bar for copying the classical private key, but it does not erase every possible compromise path or make stored data invulnerable forever.

And “TPM-backed” does not mean ML-KEM runs inside the TPM. In this design it does not. The software-held ML-KEM key remains a software secret; the hybrid makes the TPM-held operation another required component of the specified key-establishment flow.

Testing the boundary, not just the math

Cryptographic test vectors and a real TPM exercise answer different questions.

Known-answer tests can check that an implementation matches expected algorithm outputs.
A Windows integration test can check that the configured provider and key handle actually perform the P-256 operation through the expected platform path on that machine.

The second check matters. A build that references a TPM API is not proof that the operation reached a hardware-backed key. In one recorded live kem 5 check, the hybrid approval flow ran against a real TPM and passed 1/1 on a single machine. That is useful evidence that this path reached hardware in that setup.

It is not hardware certification. Vendor EK attestation and multi-machine hardware behavior remain unverified, and one successful run does not establish that every TPM, firmware, provider configuration, or Windows release behaves identically. The claim should stay scoped to what was actually tested.

The result: two failure domains, one specified construction

The useful mental model is not “post-quantum TPM.” It is two independently managed components brought together by a defined hybrid KEM:

software-held ML-KEM component ----+
                                    +--> specified hybrid secret --> envelope key
TPM-held P-256 operation ----------+

ML-KEM contributes the post-quantum side. The TPM-held key contributes a device-bound operation. Neither label should be stretched into a claim that the other component has moved into that boundary.

The lesson for me was less about picking a fashionable algorithm and more about preserving the properties we actually wanted: independent key material, a non-exportable device key, and a combiner designed and specified as a whole.

When two primitives are meant to protect against different failures, the composition is the security design. The diagram is the easy part.

References

NIST, FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard. NIST has noted that an issue will be corrected in a future update; implementations should follow the publication and its current errata.
IETF CFRG, Concrete Hybrid PQ/T Key Encapsulation Mechanisms, draft-irtf-cfrg-concrete-hybrid-kems-04. This is an Internet-Draft, not a final RFC.
Microsoft Learn, CNG Key Storage Providers and How Windows uses the TPM.

Tags: #security #windows #rust #systemsprogramming

This is an engineering narrative, not a claim of certification or a substitute for a review of a concrete implementation.

We Tried to Keep Plaintext Only in Memory. Microsoft Word Said No.

Alex — Thu, 24 Sep 2026 16:57:04 +0000

I wanted to solve what sounded like a fairly simple problem:

Open an encrypted .docx in Microsoft Word without ever writing the decrypted document to disk.

The ideal flow looked like this:

encrypted file
     ↓
decrypt requested bytes
     ↓
Windows virtual file
     ↓
Microsoft Word

Plaintext would exist only in memory.

No temporary .docx.

No cleanup problem.

No plaintext sitting somewhere on disk waiting to be copied.

Windows Cloud Files API seemed almost perfect for this.

It lets you create placeholder files whose actual content is provided on demand. When an application asks for some bytes, your provider gets a callback and returns exactly that range.

Conceptually:

fn fetch_data(offset: usize, length: usize) {
    let end = (offset + length).min(document.len());

    provide_to_windows(
        offset,
        &document[offset..end],
    );
}

So I built a small test.

The placeholder contained no document data. The provider kept the real bytes in memory and served them when Windows requested them.

Then I opened the file in real Microsoft Word.

First attempt: full hydration

In the normal hydration mode, everything worked.

Word requested the file:

offset: 0
length: 13400
process: WINWORD.EXE

The provider returned the bytes.

Word opened the document successfully.

Great.

Except Windows had now written the hydrated contents to disk.

After stopping the provider entirely, the file was still readable as a normal .docx.

So the architecture had effectively become:

encrypted file
     ↓
decrypt
     ↓
plaintext file on disk
     ↓
Word

Which was exactly what I was trying to avoid.

Second attempt: streaming

Cloud Files also has a streaming mode.

In this mode, the application can request data without permanently hydrating the placeholder.

That sounded much better.

A normal sequential reader worked:

ReadAllBytes()
→ 13400 bytes
→ success

The plaintext never became a normal file on disk.

Then I tried Word.

It failed.

Word experienced an error trying to open the file

The interesting part was that Word did request the data, and the provider successfully returned it.

So the problem wasn't that Word couldn't read the bytes.

The problem was how Word wanted to access them.

Word doesn't just read the file

A simple application might behave roughly like this:

open()
read()
read()
read()

That works perfectly with streaming placeholders.

Word does something more complicated.

It needs a representation of the file that can be backed by a Windows section object / memory mapping.

And Windows cannot create that mapping over file contents that only exist as temporary streamed responses.

The difference is roughly:

Sequential read:

ReadFile()
   ↓
provider
   ↓
bytes
   ↓
works

versus:

Word:

open file
   ↓
create mapped section
   ↓
requires locally backed data
   ↓
streaming placeholder
   ↓
fails

I reproduced the same behavior without Word.

Sequential reading worked.

Trying to create a mapped representation of the same file failed.

At that point it was clear this wasn't just a Word quirk.

The storage model itself was incompatible with what the application expected.

The practical solution

The compromise was:

1. Hydrate the plaintext file
2. Open it in Word
3. Keep it hydrated only for the active session
4. Dehydrate it when the session ends

Windows provides CfDehydratePlaceholder, which can return the file to its placeholder state.

So the final flow became:

encrypted document
      ↓
temporary hydration
      ↓
Microsoft Word
      ↓
document closes
      ↓
dehydrate
      ↓
plaintext removed

This worked.

But it changed the security model.

The guarantee was no longer:

plaintext never touches disk

It became:

plaintext exists on disk only inside a controlled working session and is removed afterward.

And that creates another problem.

Crashes matter

This is not enough:

on_document_close(|| {
    dehydrate(path)?;
});

Because sometimes there is no clean close.

The machine can lose power.

The provider can crash.

The process can be killed.

So recovery has to be part of the design:

fn recover() {
    for file in leftover_hydrated_files() {
        dehydrate(file);
    }
}

That was probably the most useful realization from the experiment:

cleanup isn't just cleanup when plaintext is involved.

It becomes part of the security model.

The larger lesson

The original idea was much prettier:

plaintext exists only in RAM

Unfortunately, software you don't control may make assumptions your architecture cannot satisfy.

And sometimes the right response isn't another workaround.

It's changing the assumption.

For applications that perform ordinary streaming reads, an in-memory delivery path can still work.

For applications like Word, the safer practical model is a temporary protected working session with explicit cleanup and crash recovery.

The experiment turned this:

protect the file

into this:

protect the lifetime of the plaintext

Not as elegant.

But much more realistic.

Can you call it end-to-end encrypted if the provider holds the keys?

Alex — Thu, 24 Sep 2026 13:58:50 +0000

'Encrypted' describes what happens to data. It does not tell you who can make that data readable again.

Consider two designs. In one, a storage service encrypts a file on its servers and manages the keys. That protects stored disks, but the service can decrypt the file when serving an authorized request. In the other, encryption happens before upload and the storage service never receives what it needs to recover plaintext. AWS documents this distinction for its server-side and client-side encryption options.
There is a harder case between those two: a server holds part of the material needed to open a file, but cannot open it alone. Does that count as end-to-end encryption? I think the useful questions are more specific.

Can the operator decrypt without a recipient?
Can it substitute a recipient?
Can it change the author’s rules? What happens when a recipient’s device is compromised?

I’m working through those questions in own project. Files carry

encrypted content,
authenticated chunks
a signed header
recipient key slots
access rules

The server participates in granting access, but its share alone is insufficient to derive the file key. That is a narrower claim than “the provider cannot affect access”: the server can deny service, and a server cooperating with a recipient is outside this protection boundary.

I also want access decisions to follow the file instead of relying on the folder or network where it happens to live.

NIST’s zero-trust architecture frames access around individual resources and least privilege, without granting trust simply because a request comes from a particular network.

Applying that idea to files raises practical questions about identity, short-lived access, offline use, and revocation. Revocation can restrict future access; it cannot erase plaintext someone has already received.

Those questions become sharper with AI agents. A pipeline may need one agent to read a document, another to transform it, and a third to publish a result. Giving the whole pipeline one shared credential is convenient, but makes it difficult to limit the damage from a mistaken or compromised step. The direction I’m exploring is scoped grants for specific files and actions, with delegation that can narrow rights. It still cannot make a model “unsee” text it was allowed to read.

The part available to try today is OpenCrate, the Rust core behind Close Crate, and OpenCrateSDK, a simpler one-recipient API for JSON, messages, and file bytes. The SDK has Rust examples and experimental source-built interfaces for Python, Java, and C++. Hosting and agent workflows are still in development. The public libraries are an early, unaudited preview.

let recipient = generate_recipient()?;
let public = recipient_public(&recipient);

let purpose = "example.invoice.v1";
let context = b"invoice:42";
let sealed = seal_bytes(&public, purpose, context, br#"{"total":42}"#)?;
let opened = open_bytes(&recipient, purpose, context, &sealed)?;

I’m interested in where others draw the boundary: would you let a service participate in short-lived access to encrypted files if it could not decrypt them alone? What evidence would you need before trusting that design in an agent pipeline?