Skip to content
Skip to content
Get started
/Security

Security

Storage obfuscation

Strong encryption already protects your file contents. Obfuscation is the layer on top that keeps your storage from advertising itself, so the repositories holding your data read as ordinary developer projects.

Why obfuscate at all

Encryption answers “can someone read this?” with a firm no. Obfuscation answers a different question: “does this look worth attacking?” Your encrypted chunks live in repositories on general-purpose platforms like GitHub and GitLab. If those repos were obviously a stash of encrypted secrets, they would draw attention even though the contents are unreadable. So zcrypt makes them look mundane.

A second layer, not a replacement

This is defense in depth. The confidentiality guarantee comes entirely from encryption; obfuscation just reduces the signal that there is anything to encrypt in the first place.

Chunk filenames

Each encrypted chunk is stored under a random hex filename with a .bin extension: the kind of name a build tool or cache would produce. There is no sequence number, no original name, and no extension that hints at the underlying file type.

example stored chunk names
a3f9c1e8b2740d56.bin
7d10e4ab9c3f8821.bin
0b5e2f7a16c94d3e.bin

Because names are random rather than ordered, the storage layout doesn't reveal how many files you have, how they relate, or which chunks belong together, that mapping lives only in your encrypted index.

Repository disguise

The repositories themselves are dressed to look like routine internal tooling rather than a storage vault:

  • •Plausible project names assembled from developer-flavored words: things like core-engine-v3 or shared-cache-v1.
  • •Rotating commit messages in conventional-commit style, such as chore: update cache artifacts or chore: refresh build cache.
  • •A generic README describing the repo as auto-managed build artifacts and cache storage, so a casual glance finds nothing of note.

Stored as private repositories

These repositories are created as private: the disguise is what they look like to anyone who does gain access, not an invitation for the public to browse them.

Storage access & scope

For zcrypt to create and write these private repositories on your behalf, the storage token you connect needs the permission to do exactly that. We will be straight about it rather than calling it “minimal.”

  • •Connecting GitHub requires a token that can create and write to private repositories, a classic repo scope grants full control of private repos. That is the access level needed to manage your storage, not a read-only sliver.
  • •The same principle applies to the other backends: the token must be able to create and write the repositories or channels that hold your chunks.
  • •Whatever the scope, the token only ever lets zcrypt move ciphertext in and out. It confers no ability to read your files.

Those tokens are encrypted at rest under a server-derived key, which is the one non-zero-knowledge surface in the system, detailed in zero-knowledge architecture.

What it does and doesn't do

  • •It does make storage repos blend in, strip identifying detail from filenames, and keep file relationships out of the storage layout.
  • •It does not hide that an account exists on the storage platform, nor the aggregate size of what is stored: a determined platform operator can see byte totals.
  • •It is not the thing keeping your data confidential. If obfuscation were stripped away entirely, your files would remain unreadable, because they are encrypted.

Don't rely on it as secrecy

Treat obfuscation as reducing attention, not as a confidentiality control. The security argument always rests on the encryption; the disguise is there to keep the encrypted store from standing out.

Where to go next