Cryptographic construction

Draft version: 11 May 2026 · companion to whitepaper v1.2

Why this page exists

The deny.sh primitive is a small piece of cryptography. The novelty is not in any single building block: AES-256-CTR is a NIST-approved cipher with well understood security properties, Argon2id is RFC 9106, and XOR is XOR. The novelty is in how the three are composed to produce a ciphertext that can be decrypted to two different plausible plaintexts under the same two passwords, by swapping the control file. This page is the prose companion to that composition, intended for engineers and security reviewers who want the construction in one read without going to the formal whitepaper. The whitepaper remains the canonical specification; this page is a guided tour with the same maths.

The reading order is: the construction in steps, the deniability claim, the security properties we get from each building block, implementation notes on what a sound deployment looks like, and what we explicitly do not claim. Anyone evaluating deny.sh for a procurement decision should be able to read this page once and have a complete picture.

The construction in five steps

Encryption takes two passwords, two plaintexts (one real, one decoy), and produces one ciphertext plus two control files. The passwords do not change between real and decoy; the control file does. The real control file, fed back into decryption with those same two passwords, recovers the real plaintext. The decoy control file, fed back into decryption with the same two passwords, recovers the decoy plaintext. Both control files together with the ciphertext are the deny.sh artefact.

1. Salt and IV: generate a 32-byte cryptographically random salt S and a 16-byte AES IV. Both are written into the ciphertext header in cleartext. This is standard practice for AEAD constructions and does not leak information.
2. Key derivation: hash each password with SHA-256 (producing a fixed 32-byte digest), concatenate the two digests, and feed the 64-byte concatenation through Argon2id with parameters t=3, m=64 MiB, p=1, v=0x13, dkLen=32. The output is a single 256-bit key K. Pre-hashing with SHA-256 fixes the input length and prevents the length-extension ambiguity where (abc, def) and (abcd, ef) would otherwise concatenate to the same byte string.
3. Payload encoding: encode the real plaintext P as a 4-byte little-endian length prefix followed by the plaintext bytes: payload = LE32(|P|) || P. The length prefix is needed at decryption time because the XOR composition pads to a fixed envelope.
4. Control data and XOR: generate random control data C of length |payload|, then compute X = payload XOR C. The bytes X are now a pseudorandom intermediate value bound to the real payload.
5. Cipher pass: encrypt X under AES-256-CTR using key K and IV: E = AES-256-CTR(K, IV, X). The output ciphertext is S || IV || E. The decoy control data C is the second output file.

Decryption is the inverse: read S and IV, derive K from the supplied passwords, AES-decrypt to recover X, then XOR with the supplied control data to recover the payload, then strip the length prefix to recover the plaintext. With the correct passwords, swapping the control file is what swaps the plaintext: the real control file yields the real plaintext, the decoy control file yields the decoy. A wrong password produces a different K and therefore a different X, which under XOR with any control data produces a different payload. The length prefix gives a clean failure signal if the decryption is incoherent.

The deny operation

The deniability comes from a second operation: given an existing ciphertext, the original passwords, and a desired decoy plaintext P', the operator can compute a new control file C' that decrypts to P'. The procedure is:

1. Parse the ciphertext, derive K, AES-decrypt to recover the intermediate value X (identical to the encryption-time X).
2. Encode the decoy plaintext as payload' = LE32(|P'|) || P', padded to |X| with random bytes if needed.
3. Compute C' = X XOR payload'.
4. Output C'. The original ciphertext is unchanged.

The critical property: C' is computed directly from X and the desired decoy. No information about the original control data C is needed or revealed. An adversary handed both C and C' alongside the ciphertext cannot determine which was generated first. This is the deniability claim, and it is a property of the XOR algebra, not of any heavyweight cryptographic machinery.

The deniability proof sketch

The formal claim is: given a ciphertext E, two passwords, and two control files C and C' producing plaintexts P and P' respectively, an adversary with access to (E, C, C', P, P') cannot determine which of (C, P) or (C', P') was generated first. The proof sketch:

1. Both control files relate to the ciphertext through the same intermediate value X by the XOR algebra: P = X XOR C and P' = X XOR C'. Equivalently, C XOR C' = P XOR P'.
2. The intermediate value X is the output of AES-256-CTR under a key derived from two passwords. Under standard cryptographic assumptions (AES-CTR is IND$-CPA secure with a uniformly random key, Argon2id is a secure key-derivation function), X is computationally indistinguishable from a uniformly random byte string of the same length.
3. Given a uniformly random X, the relationship between any specific payload and its corresponding control data is purely algebraic XOR. The XOR operation is symmetric and reversible. There is no cryptographic binding between X and any particular control-data-to-payload mapping.
4. Therefore, from the adversary's view, both (C, P) and (C', P') are equally valid derivations from the same ciphertext. The only distinguishing signal between the pair is whether the recovered plaintext is "the real one". That is a human judgement about the plausibility of the content, not a cryptographic property of the artefact.

The construction does not require the heavyweight machinery used in Canetti et al.'s 1997 paper, which formalised deniability for public-key settings under adaptive adversaries. The symmetric, single-shot setting deny.sh targets (encrypt once, generate one or more decoys, never re-encrypt under the same key) is strictly easier. The full whitepaper at /whitepaper sets out the symmetric reduction and the assumptions in detail. We do not claim a stronger result than the symmetric construction gives us.

Security properties of each building block

Each piece of the construction was chosen for a specific reason. None of them are exotic, and every one is implementable in any language with a standard cryptography library.

AES-256-CTR

The cipher is AES-256 in Counter (CTR) mode. CTR mode turns a block cipher into a stream cipher by encrypting a counter and XORing the output against the plaintext. We use it for two reasons. First, AES-256 is FIPS-approved, has thirty years of cryptanalytic scrutiny behind it, and is hardware-accelerated on every modern CPU. Second, CTR mode is the cleanest block-cipher mode for our needs: it produces a ciphertext exactly the same length as the plaintext (no padding overhead), and the IV-plus-counter structure is well understood. We do not use AES-GCM at this layer, because the authentication tag is supplied by a separate per-payload binding (the length prefix decode plus the calling application's authentication check). AES-GCM would compose differently with the XOR step and complicate the deniability proof sketch above.

Argon2id (t=3, m=64 MiB, p=1, v=0x13)

The key-derivation function is Argon2id, parameterised at t=3, m=64 MiB, p=1, v=0x13. Argon2id is OWASP's recommended password-based KDF as of 2024. The deny.sh setting deliberately exceeds OWASP's minimum recommendation of t=2, m=19 MiB while staying practical for interactive browser and SDK use. Memory-hardness makes brute-force scale with RAM cost, not just compute, dramatically raising the per-guess cost for an attacker. For comparison, a four-word English passphrase has about 44 bits of entropy, and a six-word passphrase pushes the attack beyond plausible commodity-cracking economics.

XOR composition

The XOR step is the deniability primitive. It is also the simplest piece. The security argument for the XOR is that it provides perfect secrecy when one of the operands is uniformly random (the one-time pad result). The intermediate value X in the deny.sh construction is computationally indistinguishable from uniformly random, by the IND$-CPA security of AES-CTR under a random key. So the XOR step inherits the indistinguishability of X, and the relationship between control data and payload is statistically untraceable without the right key. This is the same algebraic move used in deniable-encryption constructions going back to the 1990s. The security argument reduces to the security of the building blocks (AES-CTR, Argon2id) themselves; no attack against the XOR composition is known that does not first break one of those primitives.

Length prefix and integrity

The 4-byte little-endian length prefix on the payload serves one purpose: it tells the decryption code where the plaintext ends and any padding begins. It is NOT an authentication tag. A wrong password produces an essentially random X, which XORed with the control data produces an essentially random payload; if the length prefix happens to fit within the envelope, the SDK will hand you the resulting bytes without complaint. The construction is intentionally unauthenticated at the primitive layer, because an AEAD tag would defeat the deniability property (any tag that verifies a plaintext also proves a plaintext exists). Caller-side integrity is the calling application's responsibility: deny.sh decryption hands back bytes, the application checks whether they look like its own data. We document the recommended pattern (a short magic-bytes prefix on the plaintext, plus a SHA-256 fingerprint that the caller verifies on decryption) in the SDK documentation at /docs. Without one of those caller-level checks, a wrong-password decryption returns garbage, not an error.

Implementation notes

A correct implementation of the construction above gets the deniability claim for free. The interesting work is in not introducing side channels. Notes on what we do and what we recommend reviewers check.

Constant-time operation

The three cryptographic operations in the construction have different constant-time profiles. AES-256-CTR, implemented via the platform's native AES (WebCrypto in browsers, the standard library in Node and Rust and Go), is constant-time at the cipher level on modern CPUs with AES-NI. The XOR operation is constant-time by definition. Argon2id is a hybrid construction: the first half-pass is data-independent (Argon2i), and the remainder is data-dependent (Argon2d). Memory work dominates wall-clock time in both halves, and no practical password-recovery side-channel via Argon2id timing has been demonstrated against properly-parameterised instances at our t=3, m=64 MiB setting. The deny.sh SDKs do not introduce any password-conditional branching outside the Argon2id call itself. The implementation notes at /security-posture document the per-SDK approach. Where the host platform offers no constant-time Argon2id (very rare), the SDK falls back to a vetted reference implementation rather than rolling its own.

Memory hygiene

The real plaintext exists in process memory between decryption and use. The SDKs zero out plaintext buffers where the host runtime supports it (TypedArray .fill(0) in browsers, zeroize crate in Rust, manual zeroisation in Go and Node). Garbage-collected runtimes (JavaScript, Go) cannot guarantee that the zeroed buffer was the only copy, so we recommend keeping the decrypted material in a tight scope and not holding it in long-lived process state. The CLI and MCP server use short-lived sub-processes for decryption operations by default to limit the exposure window.

Side-channel resistance

The construction is resistant to common side channels that affect block-cipher implementations (cache-timing, branch-prediction). It is not resistant to host-level side channels that are outside the cipher's control: process memory inspection, keyloggers reading the password as it is typed, microphones detecting keystroke acoustics. These limits are set out at /threat-model.

Cross-implementation byte compatibility

Every reference SDK (TypeScript, Rust, Go, Python) produces byte-identical ciphertexts from the same input parameters. Each SDK locks the construction with three cross-SDK Known-Answer Test vectors (KAT1 covers deriveKey with fixed salt 0xAA, KAT2 covers deriveKey with fixed salt 0x01, KAT3 covers a full encrypt cycle byte-exact). The KAT3 fixture exercises the deny operation: a single ciphertext decrypts to multiple known plaintexts under different control files. Wider language-specific suites surround the KAT vectors: TypeScript ships 822 assertions across the full repo (8 in the KAT block), Rust ships 38 tests (3 named kat_*), Go ships 36 tests (3 named Test*KAT), Python ships 749 collected tests (3 in the TestKATCrossCompatibility class). A third-party implementation that passes the three KAT vectors is byte-compatible with the published reference. The KAT fixtures are at github.com/deny-sh-crypto in each SDK's tests/ directory.

Browser-supply-chain hardening

The browser SDK is delivered as two static modules from deny.sh's static origin: the deny.sh logic itself (around 9 KB unminified, 2.7 KB gzipped) and the hash-wasm Argon2id bundle (around 216 KB unminified, 76 KB gzipped). Both are integrity-pinned with Subresource Integrity (SRI) hashes that are published in the changelog at every release. The build pipeline is reproducible from the public source: a verifier at /verify takes each served bundle, re-derives the SHA-256 hash, and compares it to the latest released SRI hash. A successful match is structural evidence that the served bytes are the bytes that were built from the open-source repository. The Content Security Policy on deny.sh restricts script sources tightly; the post-launch hardening plan moves script-src off 'unsafe-inline' via per-request nonces, closing the residual gap.

What we explicitly do not claim

This is a small primitive, and we are not going to oversell it. The honest list of things this page does not cover:

• A third-party formal cryptographic audit. We have not yet engaged an external cryptographer for a paid review. Outreach for paid informal reviews begins post-launch. Until then, the public artefacts are: this page, the whitepaper, the open-source SDKs (Apache 2.0), the published KAT vectors, the SRI hashes, the reproducible-build verifier at /verify, and the coordinated disclosure policy at /disclosure.
• Authentication against active adversaries at the protocol level. AEAD-style integrity is the calling application's responsibility. The deny.sh primitive itself produces ciphertexts that an active attacker could substitute, replay, or replace. Applications that need active-adversary resistance should layer a signature scheme, MAC, or HTTPS-bound transport on top.
• Quantum resistance. AES-256 has roughly 128-bit security against Grover's algorithm. That is well above current cryptanalytic reach but does not make the primitive post-quantum. We track NIST post-quantum standardisation and will publish a position when a transition is warranted.
• Defence against operator coercion. Cryptographic deniability is a property of the artefact. Operational deniability is a property of how the operator behaves under pressure. The primitive does not promise the second. See /threat-model for the explicit list of scenarios.

Engineering controls around the primitive

The cryptographic construction above is the primitive. The deniability product is the primitive plus six engineering controls that exist in production today. Each one closes a specific class of failure that a primitive on its own cannot prevent. We name them here because reviewers reading this page often want to know what is engineered around the maths, not just what is in the maths.

• Audit chain with signed receipts. Tamper-evident hash chain over every operation, RFC 3161 timestamped by an independent TSA. Receipts are verifiable without trusting deny.sh. Dashboard at /dashboard/audit. Closes the operational-trust gap: a regulator can verify what happened from receipts alone.
• Durable usage metering. Per-tier daily metering, response headers, 80 / 95 / 100 percent email alerts. Quota events join the audit chain. Closes the silent-overage failure mode.
• BYOK envelope (AWS KMS). Server-stored ciphertext wrapped with a per-record AES-256-GCM DEK, the DEK itself encrypted under the customer's AWS KMS CMK. Customer-controlled blast-radius cap; revoke is dark.
• Pre-built integrations. AWS Secrets Manager custodian (third-party-verifiable backup of critical encrypted material), signed outbound webhooks (Datadog, PagerDuty, Slack with exponential-backoff retry and HMAC-SHA256 signatures), SAML SSO with JIT provisioning (Okta-compatible, replay protection, email domain allowlist, cross-tenant collision check).
• Compliance umbrella. Trust Center, public controls map against SOC 2 TSC and ISO 27001 Annex A, lightweight status page, honest roadmap blog. Closes the procurement-evidence gap.

For the public controls map between these moats and the SOC 2 / ISO 27001 framework criteria, see /compliance#controls-map. For the scan-friendly view, see the Trust Center.

References

• Canetti, R., Dwork, C., Naor, M., and Ostrovsky, R. (1997). Deniable Encryption. Advances in Cryptology, CRYPTO '97. The foundational formalisation; deny.sh implements the symmetric one-shot subset.
• Biryukov, A., Dinu, D., Khovratovich, D. (2021). Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications. RFC 9106.
• NIST SP 800-38A. Recommendation for Block Cipher Modes of Operation. Specifies CTR mode.
• NIST FIPS 197. Advanced Encryption Standard. The AES specification.
• Bellare, M., and Rogaway, P. (2005). Introduction to Modern Cryptography. Standard reference for the IND$-CPA security model used in the deniability proof sketch above.
• Howard, M., and Lipner, S. (2006). The Security Development Lifecycle. Background on the side-channel and implementation considerations referenced above.

Related pages

• /whitepaper: canonical specification (v1.2, May 2026) with the full algorithm, security analysis, and threat-model treatment in formal language.
• /threat-model: what the primitive defends against, what it does not, and why the agent use case is the strongest fit.
• /security-posture: operational security controls, infrastructure, jurisdiction, and licensing.
• /disclosure: coordinated security disclosure policy.
• /verify: reproducible-build verifier for the browser SDK bundle.

Talk to us

If you are reviewing the construction for procurement, integration, or academic interest, write to hello@deny.sh. We respond to construction questions on a same-week basis and to research enquiries on a same-day basis where possible. Suggested corrections to this page or the whitepaper are welcomed and credited in the changelog.

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.

Bulk leak of at-rest ciphertext

Cloud-synced backups, lost laptops, exfiltrated S3 buckets, stolen hard drives, abandoned office machines, forgotten git history, breached password managers. The adversary holds a file. They do not hold you. They have no way to ask for a password except by guessing, and a guess that decrypts to plausible cover is indistinguishable from the correct password. They take the decoy and move on, because there is no reason to think anything else is there. This is the cleanest fit for the primitive and the largest single category of real-world exposure.

Prompt-injected AI agents

This is the use case the rest of the cryptography literature does not yet address. An AI agent that holds a credential is a credential leaking outwards under adversarial pressure. Prompt injection, jailbreaks, malicious tool output, hostile web pages parsed during a task. Any of these can extract whatever the agent is currently holding in its context window. With deny.sh, the agent only ever holds a control file that decrypts to a plausible decoy credential. The real key never enters the agent's context. When the attacker successfully exfiltrates a secret, what they have is a decoy that authenticates against nothing important. The agent is, in cryptographic terms, the adversary in its own threat model, and it cannot suspect anything outside its context window. That is what makes the agent case structurally strong.

Casual forensic review

A device handed in for repair, returned at the end of an employment relationship, inspected at a customs checkpoint by an officer with no specific suspicion, or analysed by a routine forensic tool. The artefact is high-entropy bytes that decrypt cleanly with the password the operator typed. There is no signature that another plaintext exists. The published forensic-detection literature on hidden-volume systems describes a number of side-channel signals (filesystem timestamps, slack space, application metadata) that can suggest the presence of a hidden volume. deny.sh avoids these by design. A deny.sh ciphertext is a single, ordinary, encrypted-looking file. It does not sit inside another volume. It does not require special filesystem behaviour. It looks like every other encrypted blob.

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. The primitive protects the file at rest and protects the agent context against prompt-injection exfiltration. 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 (one runtime dependency in the SDK, hash-wasm, audited and pure-WebAssembly) are how we narrow this gap. They do not close it.

Coerced disclosure with no ceiling

The XKCD comic is correct. An adversary willing to apply unlimited physical coercion until they get all the plaintexts you know of is not an adversary that any encryption primitive defeats. Some deniable-encryption products pitch themselves at this scenario. deny.sh does not. Operational deniability against a one-shot demand is plausible. Against an adaptive adversary with iterative demands, the operator is the weak link, not the ciphertext. If the threat model is rubber-hose attack, the right tool is jurisdictional separation and physical absence, not a deniable file format.

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.

Why the agent use case is the strongest fit

The limits described above mostly involve a thinking adversary outside the file, applying pressure to the operator. The agent case removes that adversary almost entirely.

An AI agent has no theory of mind. It cannot suspect the presence of a second plaintext that is not in its context. It does not refuse to accept a decryption as final and ask for another one. It does not film the operator at the keyboard. It cannot patiently make repeated password demands while observing reactions, because it does not observe the operator at all. The adversary in the agent case is the agent itself, and the agent is bounded by what is in its context window. Put the real key outside that window, and the agent has no path to it. Put a plausible decoy inside that window, and the agent will hand the decoy to any attacker that successfully prompt-injects it. The decoy is what the attacker gets, every time, by construction.

This is also why we lead with agents at launch. Most of the consumer scenarios the primitive supports (encrypted backups, travel-resistant storage, succession planning, secret photography) involve a human operator who can be pressured. The agent scenario does not. The strength of the primitive shows most cleanly there.

The cryptographic primitive at a glance

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

• Cipher: AES-256-CTR under a single 256-bit key K, applied to the XOR intermediate (not to the plaintext directly).
• Key derivation: SHA-256 prehash of each password, concatenated, fed through Argon2id (t=3, m=64 MiB, p=1, v=0x13) into one 256-bit key K, with per-payload random salt. An archival preset (N=2^17) is on the post-launch roadmap.
• Composition: the padded payload is XORed with random control data C to produce the intermediate X, then X is encrypted under AES-256-CTR. Swapping the control file is what swaps the plaintext. The XOR is the deniability primitive. Without the correct password, no party can determine which decryption is the truth and no party can determine that a second plaintext exists.
• Integrity check: the construction is intentionally unauthenticated (an AEAD-style tag would break the deniability property: a real tag verifies; a tag-with-no-tag does not, and the asymmetry is detectable). Instead, integrity rests on a 4-byte length prefix inside the encrypted zone. A wrong password produces a random length prefix that overwhelmingly fails sanity checks (length > envelope) and a random payload that overwhelmingly fails the calling application's own format check. The recommended pattern, documented at /docs, is for the caller to prepend a short magic-bytes prefix to the plaintext and verify it on decryption.
• Surface: the TypeScript SDK core is about 3.3 KB minified (1.2 KB gzipped), browser-compatible, with one runtime dependency (hash-wasm for portable Argon2id). The CLI, Telegram bot, Chrome extension, and MCP server are thin wrappers over the same primitive.

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.

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.

• Browser-supply-chain: the served bundle has Subresource Integrity hashes, the build is reproducible from the public source, and the CDN edge is fronted by Cloudflare with a tight Content Security Policy. The post-launch hardening plan moves CSP script-src off 'unsafe-inline' via per-request nonces.
• Dependency surface: the TypeScript SDK has one runtime dependency, hash-wasm, which provides the portable Argon2id implementation. hash-wasm is a pure-WebAssembly module with no further runtime dependencies of its own and is published as a single audited bundle. The CLI, Telegram bot, Chrome extension, and MCP server carry their own dependency trees but are not loaded by the SDK itself. A bundler that imports just the SDK pulls in hash-wasm and nothing else.
• Memory exposure at decryption time: we recommend short-lived decryptions in a dedicated process, zeroisation of plaintext buffers where the host runtime supports it, and not holding decrypted material in long-lived process memory.
• Operational deniability: deny.sh ciphertexts are indistinguishable from random bytes at the file level. Operators are responsible for the surrounding operational hygiene (filesystem traces, application metadata, browser history) that no encryption primitive controls. The documentation in /docs covers the most common operational pitfalls.
• Jurisdiction: the operator of the deny.sh hosted API is Treehouse in Valhalla Ltd, a UK private limited company. UK jurisdiction includes the Investigatory Powers Act 2016 and its Technical Capability Notice regime. Our position on what this means in practice, including the structural limits on what a TCN can compel against a client-side primitive, is set out at /security-posture. Customers requiring jurisdictional separation can self-host the SDKs (Apache 2.0, the source is fully open) or self-host the application-layer code (AGPL-3.0).

References and prior work

• Canetti, R., Dwork, C., Naor, M., and Ostrovsky, R. (1997). Deniable Encryption. Advances in Cryptology, CRYPTO '97. The foundational formalisation of deniable encryption.
• Bertoni, G., Daemen, J., Peeters, M., and Van Assche, G. (2012). Sponge functions and the design of SHA-3. Background on the constructions used for authenticated derivation.
• Biryukov, A., Dinu, D., Khovratovich, D. (2021). Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications. RFC 9106.
• Forensic-detection literature on TrueCrypt and VeraCrypt hidden volumes describes the side-channel signatures of hidden-volume systems. deny.sh avoids these signatures by not using a hidden-volume model; each ciphertext is a single ordinary file.
• Bellare, M., Boldyreva, A., and O'Neill, A. (2007). Deterministic and Efficiently Searchable Encryption. Background on ciphertext-indistinguishability bounds.

The full construction proof-sketch and implementation notes are at /security. The current operational security posture is at /security-posture. 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.