Why deniable encryption matters more than you think

Every encryption tool protects bytes from people who don't have the key. None of them protect the bytes from being seen for what they are once the bytes leave your control. That second problem is the one nobody talks about, and it's the one deniable encryption is built to fix.

The bytes leave more often than people think

Standard encryption assumes a clean game. You hold the key, the attacker doesn't, the bytes stay safe. The model breaks the moment the bytes themselves move into a place you no longer control. That happens far more often than security marketing implies:

• A cloud provider gets breached and dumps a backup table to a forum.
• A laptop walks off after a conference. The disk is encrypted, but the encrypted backup file you synced last night is now sitting on the thief's drive.
• An .env file with a real API key gets pushed to a public repo. GitHub's secret scanner pages someone five seconds later, but the file is already in the public log.
• An AI agent loaded with credentials gets prompt-injected into reading and exfiltrating its own context.
• A SaaS data export, requested for legitimate reasons, lives forever in someone's downloads folder.

In every one of those cases, encryption did its job: the bytes are still ciphertext. But ciphertext alone gives an attacker a binary outcome. Either they have the key and the file opens, or they don't and they keep trying. The bytes themselves give them no other dimension to work with.

The third dimension

Deniable encryption adds the dimension that's been missing. The same ciphertext decrypts to completely different content depending on which key you use. One key gives the real plaintext. Another gives a plausible decoy. Both decryptions are valid. Neither is provably "the real one" from the bytes themselves.

The maths is well studied. Anderson described the construction in 1996, Canetti formalised it in 1997. What didn't exist for most of that time was a usable implementation that ran in a browser, shipped as an SDK, and didn't ask you to mount a hidden volume.

The construction at deny.sh/encrypt uses scrypt key derivation, AES-256-CTR for the encryption, and XOR composition over key material to bind multiple plausible plaintexts to one ciphertext. SDKs in TypeScript, Rust, Go, and Python are open source under Apache 2.0; the hosted application layer is open source under AGPL-3.0. All verifiable in your browser at deny.sh/verify: 22 tests covering chi-squared, entropy, and fuzz coverage. Independent third-party cryptographic audit is on the roadmap; firm and scope will be announced once engaged.

Where it actually applies

The honest framing is that this is for at-rest data that needs to fail closed when it leaks. Concrete cases:

Developer secrets. API keys, OAuth tokens, signing keys, and the contents of .env files. Cloud backups and repo history are the leak path; deniable encryption means the leak surrenders a decoy.

AI agents holding credentials. Prompt injection is now a routine attack. An agent that only ever sees a decoy control file can be tricked into reading its full context out loud and the real key still doesn't appear. The real one stays separated, decrypted only when the agent finishes a task and a different process unwraps it.

Cloud-backup defence in depth. Treat the cloud breach as when, not if. Encrypt your backups so the encrypted blob, even after a full provider compromise, opens to a decoy.

Pre-positioned decoys for known scenarios. Devices crossing borders, laptops attending sensitive meetings, M&A deal-room machines. Bounded threat model, scriptable workflow.

Regulated at-rest data. Healthcare PHI, deal-room secrets under privilege, family-office records. Breach safe-harbours already exist for encrypted-at-rest data; deniability simplifies the post-breach narrative because the leaked bytes don't even reveal real content under analysis.

Where it doesn't apply

This part matters more than the marketing. Deniable encryption isn't magic and it isn't a defence against an adaptive attacker who already knows the tool exists in your life. If someone is watching you, holds your subscription records, or otherwise knows you store things deniably, they don't stop after the first decoy. They keep asking for more passwords. The maths holds. The behaviour around it does not.

It's also not a substitute for not having the file. If you're carrying something genuinely high-risk, the right move is still: don't carry it. deny.sh is for the case where bytes need to exist somewhere and you want them to fail closed when they leak.

And the believability is on you. The decoy has to make sense in context. A wallet with $0 in it doesn't. A wallet with $150 and three transactions in 2024 does. The product gives you the cryptographic guarantee. The plausibility is your job.

The point

Standard encryption gives you one decryption. Deniable encryption gives you two. When a backup leaks, when a device walks off, when an agent gets prompted out of a secret, the file decrypts to your decoy. The real content never appears in the breach.