How deny.sh compares.

VeraCrypt is the closest competitor in the deniability space, and the only tool here we recommend pairing with deny.sh rather than replacing. Its threat model and ours are different.

VeraCrypt encrypts whole volumes or whole disks. A hidden volume sits inside the unused space of an outer volume; you can mount the outer with one password and the hidden one with another. This works well when the threat is offline analysis of a stolen drive.

The hidden-volume mechanism has structural limits. The outer volume is a fixed-size encrypted container. The hidden volume lives in what looks like free space, and recent accesses to the outer volume can corrupt or overwrite the hidden one if you forget to mount in protect-hidden mode. Forensic analysis of the free-space distribution and the file system metadata can sometimes flag the presence of a hidden volume; the security relies on the outer volume looking convincingly used.

TrueCrypt is the predecessor; development stopped in May 2014 with the cryptic using TrueCrypt is not secure notice. Historical audit reports do not substitute for ongoing maintenance. People still use it; we don't recommend it given the lack of maintenance.

deny.sh has no volumes, no containers, no free-space heuristic. A single file decrypts to different valid plaintexts depending on which control file is supplied. File size and surrounding metadata remain visible; padding can reduce length detail. Both passwords are required together, and the control file selects the message.

Where VeraCrypt wins: full-disk and full-volume encryption. If you need an encrypted operating system partition or a 2 TB hidden archive, VeraCrypt is the right tool. Use both: VeraCrypt for the disk, deny.sh for individual files that need cryptographic deniability.

CipherEdge is the closest tool to deny.sh on the consumer side: browser-based, client-side AES-256-GCM, zero-knowledge (the key lives in the URL fragment and never reaches their server), and a real-plus-decoy story aimed at the same seed-phrase, journalist and coercion use-cases. It's well-built and the threat model is one we take seriously.

The difference is structural, and CipherEdge states it plainly: its two secrets are created completely independently, each stored as a separate, unlinked record, which it describes as structurally identical to VeraCrypt's hidden volume. Deniability there is a property of the storage layout (the server holds two blobs and claims it can't link them) rather than of a single construction. That puts the security on the assumption that nothing (creation order, timing, access logs, backup snapshots, traffic correlation, or a future metadata leak) ever ties the two records together.

deny.sh is one ciphertext, multiple plaintexts. There is one ciphertext, but separate control files still require secure handling. With both passwords together, one encrypted file opens to the real message or a chosen fake depending on the supplied control file. The construction provides alternative messages; operational protection still depends on keeping real control material separate. There is no which one was made first question encoded as a real-versus-decoy flag, but external evidence can still distinguish the files or messages.

Evaluate each product’s current implementation and processing boundaries. deny.sh’s local tools keep inputs on your device; hosted encryption receives them. Neither a single ciphertext nor separate records guarantee protection from backups, access patterns or other external evidence.

age is the modern successor to PGP for file encryption. Clean format, sensible defaults, ChaCha20-Poly1305 AEAD with X25519 key agreement. We respect it; it's well-designed encryption software.

age does not natively claim deniability. Its files start with a recognisable age-encryption.org/v1 header line; the file is unmistakably an age-encrypted file. Several experimental wrappers exist (decoy stubs, dual-recipient tricks, pure header stripping) but none of them ship a formal deniability proof and most introduce detectable structural irregularities of their own.

The core deny.sh file contains a salt and initialisation-vector header, encrypted data and no authentication tag. It supports chosen decoy messages through separate control files; that is different from hiding whether encryption was used.

PGP encrypts a file. It does this well, has a long history of implementations and review, and underpins most of the email and software-signing world. It also makes no deniability claim.

A PGP-encrypted file is unmistakably a PGP-encrypted file. There's a packet header, a recipient key id, often an ASCII armor wrapper. The format reveals that encryption was used; the recipient key id can identify the intended reader. There is no decoy, no second plaintext, no construction-level deniability.

If you're trying to deny that anything was encrypted at all, or to produce a different valid plaintext on demand, PGP is the wrong tool. If you want strong asymmetric encryption with a long audit history and broad ecosystem support, PGP is fine.

Off-the-Record Messaging and the Signal Protocol both implement cryptographic repudiation for live conversations. Forward secrecy plus malleable MACs mean that any single message can be forged after the fact by either participant; you can't prove who wrote what.

This is a different threat model. OTR-style deniability defends a conversation participant against a transcript being used as evidence. It applies to live, two-party messaging with key rotation, not to data sitting on a disk or in a backup.

deny.sh is for at-rest data. Files in cloud-synced backups, vault entries on a stolen laptop, agent secret stores, archived datasets. If you need deniable messaging, use Signal or OTR. If you need deniable storage, use deny.sh. They don't compete; they cover different surfaces.

Thinkst Canary, the Canarytokens project, and the broader honeytoken category (AWS canary keys, GitGuardian honeytokens, Spectral, Doppler decoy secrets) all answer the same question we do: did someone touch the fake credential I planted? They do it well, and we don't compete with them on the perimeter use-case.

The difference is the layer. Honeytoken services fire when the token is used against the issuing service (a fake AWS key gets exercised against IAM, a fake API token hits a webhook, a DNS canary gets resolved). They sit on the network and watch for the call. Their coverage depends on the token type and monitored service.

deny.sh tripwires fire when the decoy is recovered from a decrypt call against our endpoint. We see the controlData parameter (controlData-kind tripwire) before decryption runs and we see the recovered plaintext (plaintext-kind tripwire) after it runs. The match happens inside the deniable-encryption substrate, where the attacker has already committed to decrypting. This monitoring does not observe offline decryption or tests against the credential’s real provider.

The use-cases are complementary. Plant a Thinkst Canary in your S3 bucket for perimeter alerting. Use deny.sh tripwires for the moment a decoy plaintext is recovered from a deniable-encrypted credential vault. Different layers, different alerts, different attacker phases.

A newer class of defence targets the same problem deny.sh was built for: a tool-using LLM agent that gets talked into leaking its own credentials via prompt injection. Two patterns dominate. Agent deception frameworks (for example AgentShield, a 2026 research framework) plant traps inside the agent's tool interface, fake tools whose invocation signals compromise, honeytokens that should never appear in legitimate traffic, and allowlisted-parameter checks. Credential brokers / proxies (the agent never holds the secret pattern) keep the real key at a network boundary and resolve it on the agent's behalf, so a compromised agent has nothing in context to exfiltrate.

Both are good ideas and we don't compete with either head-on. They operate at the interface and the network: detect a misused tool, or keep the secret out of the model's reach in the first place. deny.sh operates one layer down, at the secret itself. The credential is stored as a deniable ciphertext, so the value the agent can resolve and disclose is already a believable decoy, and monitored decryption can trigger an alert if the relevant fingerprint is registered.

Evaluate what happens if a boundary fails: an over-scoped tool, a path-traversal, a misconfigured proxy, a future capability the allowlist didn't anticipate. A correctly enforced broker keeps the key out of context. Any failed boundary must be assessed by what it exposed. A honeytool detects an agent reaching for a fake tool; it says nothing about the agent reading a real secret store aloud. deny.sh adds protection only while access to real control material and passwords remains restricted. If the real key leaks, a decoy does not undo that exposure. Use monitoring alongside existing controls, not as a guarantee when they fail.

An honest comparison cuts both ways. A few things to be clear about:

• Not a full-disk encryption tool. Use VeraCrypt or BitLocker or LUKS for that, optionally on top of a deny.sh-encrypted file.
• Not a messaging protocol. Signal and OTR cover live conversation deniability. We cover stored data.
• Not protection against an adversary who can compel you to decrypt and observe whether you do. Cryptographic deniability defends against ciphertext leak, not against being watched while you type a password. See threat model.
• Not externally audited yet. The construction is published in the cryptographic write-up with a proof sketch, and the SDKs ship full byte-compatibility test vectors across four languages. Independent audit is on the roadmap.