Encrypt the real key.
Choose the fake.
Building with AI agents? Try encrypting a credential and choosing a decoy in your browser. Keep the real key and its control file inside trusted software.
Write. Encrypt.
Keep the files apart.
One encrypted object. Two separate control files (files that select which message opens).
- 01Write both messages
Enter the real message and your chosen decoy (a believable fake secret or message).
- 02Encrypt with two passwords
You always need both passwords, whichever message opens.
- 03Save and separate the files
Keep the real control file away from what you reveal.
Both passwords together
Enter a private message, an API key (a service access credential), a recovery phrase or a file. Your message and passwords stay in this browser.
The plausible alternative. This is what the decoy control file reveals. Choose a message that fits the context. External evidence can still distinguish it from your real message.
For supported formats, a wrong password/control combination returns a fake with the right shape instead of garbage. The same wrong inputs return the same fake. Learn how it works.
🔒 Generated in your browser. Only the secret type (e.g. "stripe-live-key") is sent to shape the sample, never your actual secret or ciphertext.
Choose two strong passwords and keep both safe. Argon2id, a password-to-key function, combines them into one encryption key. This tool does not save either password.
Both passwords are needed together. This tool does not save them.
🔒 Encryption stays in your browser. Live decoy suggestions send only a type label.
✓ Encrypted successfully
One encrypted file. Two control files. Two possible messages.
How to use these files: Store the ciphertext anywhere safe. Keep the real control file somewhere only you can access. Put the decoy control file somewhere plausible, like a notes app or a drawer. The decoy control file reveals your chosen decoy when used with both passwords. Keep the real control file separate; exposure of it changes the protection.
Keep this safe. With this + your passwords, you get the real message back.
This opens your chosen decoy with both passwords. External evidence may still reveal that it is a fake.
Before you leave: Save honey-mode.json with the ciphertext. Keep the real control file separate.
Each file downloads separately, so you can store the real control file apart from the others.
Want to do this from your code?
Use a free local SDK, or get an API key for 500 hosted calls/month. Hosted encryption receives your message and passwords. No card required.
Get a free API key →The encrypted hex you stored or were given. Either paste it directly or upload the .enc file.
A control file selects which message opens. Use the real control file to recover your real message. Use the decoy control file to recover the decoy.
Both passwords are required to decrypt, exactly as when you encrypted.
Add the honey-mode.json downloaded with a Honey Mode record so wrong passwords return the intended plausible fake. Leave this off for classic records.
Drop honey-mode.json here or browse
✓ Decrypted successfully
Here is what that ciphertext + control file + passwords combination reveals.
Done? Copy what you needed and close this tab. Your decrypted content was never sent to a server, but it is on your screen now.
Local encryption. A clear boundary.
Encryption runs in your browser. The optional live decoy engine sends only a type label, never your secret or ciphertext. Encryption in this page stays in your browser. Our hosted API is separate: it receives what you send it. Inspect the implementation:
The encryption uses AES-256-CTR with keys derived via Argon2id. Standard, well-studied primitives. The deniability comes from how they are composed with control data. The underlying algorithms are established; their combination here is novel (patent pending) and open source. Review the construction’s current status.
deny.sh is open source: the SDK is Apache 2.0, the application layer is AGPL-3.0. You can read every line. You can run the browser verification suite yourself. Inspect the checks and their limits.
Need to store your control files securely? Use the encrypted vault.
For the full technical specification, read the whitepaper.
Best practices.
Deniable encryption is one layer. To get the most out of it.
Make your decoys believable. An empty string or "test123" won't fool anyone. Use something that matches the kind of data you'd plausibly have. Non-working example credentials or mundane notes. Never use another real secret as a decoy. The ✨ Generate a random decoy button above picks a shape-correct decoy across 69 credential types if you'd rather not write your own.
Use strong, unique passwords. Deniability protects the bytes when they leak, not against weak passwords. Use 12+ characters, mix types, don't reuse them.
Store control files separately from the ciphertext. Anyone with the real control file and both passwords can read your real message. Keep them away from material you may reveal. Use the vault, a hardware wallet, or a separate device.
Don't rely on a single tool. Combine deny.sh with hardware wallets, multisig, air-gapped machines, and good physical security. Choose additional controls to match your risks.
Add encryption to your app.
Open beta is available. Explore the local SDKs or hosted agent infrastructure.
What to know before production.
The construction combines established primitives in a novel design. An independent cryptographic audit is planned and is not complete. Browser verification checks implementation behaviour, not a security proof.
A chosen decoy is not a guarantee against coercion or external evidence. Keep real control files separate and use strong, unique passwords.