Threat model

For security and procurement review: what the design protects. Check the conditions needed for protection, the limits that remain and the evidence your deployment requires.

what the design protects. Comments and challenges welcome at hello@deny.sh. We update this page when we learn something new.

Living document. Last reviewed: 11 May 2026.

Start with your risk

Use this page to decide whether the design fits your risks. Deniability offers a chosen alternative message; it does not make compromised systems safe or guarantee that another person accepts the alternative.

For browser and core code libraries (SDKs), one encrypted file (ciphertext) opens to two messages (plaintexts). Both passwords are always required together. The control file, a separate file you keep safe, selects the real message or a chosen fake (decoy). A wrong password/control combination returns plausible garbage without an error; Honey Mode returns a fake in a supported format instead. The Telegram bot and protect-seed wizard differ: each control file is bound to its own password. The combination used here awaits independent cryptographic review.

That is the primitive. The interesting question is when the primitive helps and when it does not.

What deny.sh defends against

deny.sh is built for adversaries who acquire your ciphertext and then have to decide what to do with it. The three concrete scenarios where the primitive earns its keep are below.

Four-quadrant grid of deny.sh threat scenarios. Top left: Hostile LLM context, prompt injection and tool-use attacks. Top right: Stolen disk or backup, ciphertext under adversary control. Bottom left: Coerced password reveal, plausible deniability under duress. Bottom right: Compromised destination API, per-call isolation.
Illustrative threats to consider. Out of scope: full-disk encryption, secure messaging, under-compulsion crypto.

Bulk leak of at-rest ciphertext

If someone obtains only encrypted data, strong passwords and separate control files remain important. A person given both passwords and only the decoy control file can open the chosen decoy. Wrong guesses produce garbage, or supported-format fakes with Honey Mode. External evidence may identify a fake; there is no guarantee that an attacker stops searching.

Prompt-injected AI agents

Prompt injection is an attempt to make an agent follow hostile instructions in material it reads. If your integration gives the agent only a decoy or reference, it cannot extract a real key from that material. Keep the real control file, passwords and resolved key inside trusted software. The agent may still misuse an authorised tool, and a compromised runtime may expose the key.

Casual forensic review

A decoy can provide an alternative message when a file is inspected. This does not hide use of deny.sh, filesystem metadata, backups, logs or other evidence. A single encrypted file avoids the need for a hidden volume, but it does not guarantee that forensic analysis cannot distinguish the messages.

What deny.sh does not defend against

Every cryptographic tool has limits. The product is more useful, not less, when those limits are written down honestly.

A targeted adversary who already suspects deniable encryption is in use

If an adversary believes you specifically are using deny.sh, sees a deny.sh ciphertext on your device, and is willing to make repeated password demands while observing your reactions, the primitive does not promise to save you. You are now in operational-deniability territory, not cryptographic deniability. The construction protects the mathematical fact that two plaintexts coexist. It does not protect against an adversary who is patient, well resourced, and uninterested in accepting any decryption as final.

Compromise of the host operating system or process memory

deny.sh decrypts in the operator's own environment. Browser, CLI, SDK, MCP server. While the real plaintext is being read, it exists in memory. A kernel-level adversary, a malicious browser extension, a compromised package in the dependency tree, or a memory-snapshot attack against a running process can read that plaintext at the moment of use. Keeping real keys outside agent-accessible paths can limit exposure from its context. It does not promise host integrity that the operating system itself does not promise. Reproducible builds, signed releases, SRI hashes on the served bundle, and a tight dependency surface (including the browser dependency hash-wasm, a WebAssembly module) are how we narrow this gap. They do not close it.

Coerced disclosure with no ceiling

Encryption does not protect a person from coercion. A decoy is not a guarantee of safety, acceptance or compliance with a disclosure demand. Assess personal, legal and operational risks separately.

Multi-try Honey Mode distinguishers

Honey Mode returns deterministic fakes for wrong password/control combinations: the same wrong inputs give the same fake. Repeated guesses, known real values or checks against the provider may distinguish those fakes. It does not guarantee protection against a repeated-attempt adversary or physical coercion.

Targeted side-channel observation of the operator

If the operator is being filmed, keylogged, or microphone-monitored while they decrypt, the primitive does not help. The adversary is reading the password directly. This sounds obvious, and it is, but it is worth saying.

What makes an agent integration useful

Agents are a useful integration case because you can control which tools and credentials they can access. The protection comes from enforced access restrictions, not assumptions about how the model reasons.

Keep the real key outside the model’s conversation, tools, logs and readable files. Let trusted code use it and return only approved results. A decoy inside the agent’s context can be exposed instead, but only if every route to the real credential remains restricted. Test this boundary and authorised-tool misuse separately.

The same design may suit private files, but the surrounding risks differ. Decide by where the real control material can be kept and what evidence an adversary can obtain, rather than by the presence of a decoy alone.

The cryptographic primitive at a glance

For the formal construction, see /security. In summary:

Cross-SDK known-answer tests lock the construction across all four published SDKs (TypeScript, Rust, Go, Python). Each ships the same three KAT vectors (KAT1, KAT2, KAT3) covering deriveKey on two fixed salts and a full encrypt cycle that is byte-exact across languages. Any third-party implementation that matches all three KAT vectors is byte-compatible with the published reference.

Confidentiality and deniability, not integrity

The core scheme uses AES-256-CTR without a message authentication code (MAC), a check for unauthorised changes. A wrong password/control combination returns plausible garbage without an error, or a supported-format fake with Honey Mode. If your application needs integrity checks, review how those checks affect deniability and avoid exposing a real-versus-decoy signal.

What encryptRecord protects and what it does not

The encryptRecord API encrypts structured key-value records and generates a decoy record whose values are realistic fakes. This provides value-deniability: the decoy record has plausible-looking field values rather than the real ones. It does not provide schema-deniability.

Specifically: the decoy frame uses the same field names and type classes as the real frame, because realistic decoys require structural similarity. An attacker who coerces a successful decoy decrypt learns the field names and type classes of the real record (for example, "this record has a field named api_key whose value is a Stripe live key"), even though the actual value is a decoy. Only the values are protected, not the schema.

If full schema-deniability is required, encrypt the entire record as a freeform blob using the base encrypt() function with a hand-crafted decoy of the same byte length. This hides field names, field count, and type class, at the cost of manual decoy construction.

Decoy realism and context-distinguishability

Supported decoys are checked for format and checksum validity, called deep-valid: the generator checks supported formatting rules before returning a candidate. A credit-card decoy passes the Luhn checksum, a seed-phrase decoy has a valid BIP-39 checksum, an IBAN decoy satisfies ISO 7064 mod-97, a Bitcoin WIF key passes Base58Check, and so on. An adversary who runs each candidate through a local format check (Luhn, BIP-39 checksum tool, IBAN check-digit library) gets a pass on both the real value and the decoy. A passing checksum is not proof that a credential is live or indistinguishable from a real one. See /how-it-works for the full distinguisher analysis.

What deep validity cannot do is judge context. The maths makes a decoy checksum-valid and the right size; it cannot decide whether "a checksum-valid credit card number" makes sense as the thing you'd actually have stored there, or whether your decoy message reads like something a real person would hide. Provider validation and other external evidence can also identify a fake.

The consequence for your threat model: choosing a plausible-in-context decoy is the human half of deniability and it stays with you. A decoy that is perfectly checksum-valid but obviously out of place (an empty wallet next to evidence you trade daily, a decoy note that contradicts your situation) can still be distinguished by an adversary who reasons about context rather than just running a validator. For high-stakes field types, hand-craft the decoy with the base encrypt() API so it is both deep-valid and contextually believable.

Distributional realism is a separate axis from checksum-validity, and we do not claim to have closed it at corpus scale. A real provider credential carries distributional signatures beyond its checksum: prefix conventions, character-class ratios, entropy profile, embedded version or region markers. A format-checked decoy passes the supported local checks, not necessarily provider validation, but an adversary who specifically suspects deny.sh, holds a large corpus of genuine values for that credential type, and runs a statistical classifier may be able to separate generated decoys from reals at better than chance. This is another reason not to assume an attacker will accept a decoy. Narrowing it is active work on the realism engine; we will not overclaim statistical indistinguishability we have not measured.

What we don't hide (metadata that still leaks)

Deniable encryption operates on the contents of a ciphertext. It is not invisibility. A class of side-channels remains observable to anyone with the right vantage point, and we name them here rather than make you discover them.

These are limits to evaluate, not evidence that every deployment is safe. Decide whether the remaining exposure meets your requirements.

How we narrow the residual risk

The limits above are real. Some of them we close partially. None of them we pretend do not exist.

Defences in production today

Hosted controls add key custody, activity records and notifications. They reduce specific operational risks but do not remove the limits of the encryption design.

What the controls deliberately do NOT close: the cryptographic primitive itself (covered by the construction at /security), operational deniability outside the hosted runtime (see the operational deniability bullet above), and the residual jurisdictional risk (see the jurisdiction bullet above). The controls are layered defences around the primitive, not a substitute for it.

References and prior work

The full construction proof-sketch and implementation notes are at /security. The current operational security posture is at /trust. Coordinated security disclosure policy is at /disclosure.

If you have a scenario in mind

If you are evaluating deny.sh for a specific threat model and want to talk through whether it is the right fit, write to hello@deny.sh with a one-paragraph description. We will tell you honestly when the primitive is the right tool and when it is not. Include the data involved, who can access it and which systems must remain outside the trust boundary.