How deny.sh compares.

VeraCrypt and TrueCrypt: hidden volumes.

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. The OCAP audit later that year found the cryptography was sound. 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. The file size is fixed by the plaintext, not by an outer container that has to be plausibly populated. There is no analogous metadata-side-channel.

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.

age and the experimental wrappers.

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.

deny.sh ships no header, no version line, no recognisable bytes. The ciphertext is indistinguishable from random data of the same length. The deniability is a property of the construction, not of how the file is wrapped after the fact.

Why PGP/GPG isn't deniable (and never claimed to be).

PGP encrypts a file. It does this well, has been audited for thirty years, 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. When the file leaks, the existence of the encrypted file is itself the leak; 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.

OTR / Signal: deniability for messages, not files.

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.

What deny.sh is not.

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.