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?

DEV Community: Alex