The $5 wrench problem and the leaks that surround it

There's a famous XKCD comic about cryptography. The setup: two security experts marvel at a scheme with 4096-bit RSA keys, Twofish/Rijndael cascading encryption, and GPU-cluster-resistant hashing. The punchline: a stick figure with a $5 wrench beats the information out of someone.

It's funny because it's true. And if you hold crypto, the punchline is the part that should worry you most. Cryptography stops working the moment a sufficiently motivated adversary can keep asking you for passwords. The maths holds. The behaviour around it does not.

What the wrench actually defeats

An attacker who already knows you hold crypto, knows where you live, and is willing to keep applying pressure is not a cryptographic problem. They are a physical-security problem. Strong encryption, hardware wallets, multisig, even deniable encryption: none of those primitives stop a person standing in front of you who is willing to keep asking. If they get one decoy and they suspect there's another, they keep asking. If they get the wallet they were promised and the on-chain history doesn't match, they keep asking. The maths is not the bottleneck.

That part of the threat model belongs to physical security, opsec, threshold signing across geographies, and a willingness to walk away from holdings rather than reveal them. We can't help with that part. We won't pretend to.

What deniable encryption actually addresses

The wrench is the limit case. Most ways crypto goes missing in 2026 are not the wrench. They're the leaks around it.

• The cloud-synced backup. Your seed-phrase backup got auto-uploaded by a sync client you forgot was running. Years later, the provider gets breached and a backup table ends up on a forum.
• The lost laptop. Conference, taxi, hotel-room break-in. The disk encryption holds at boot, but the encrypted seed backup file you saved to Documents is now in someone else's hands and they have plenty of time.
• The discovered metal plate. Burglar takes the safe, forces it open in their own time, runs the words through a script that checks balances. You never see the plate again. You also can't change the seed.
• The agent that read its own context. An AI agent holding a wallet key gets prompt-injected into reading and exfiltrating its own context. The key is now sitting in someone's logs.
• The forgotten repo commit. A seed phrase ends up in a config file, gets committed to a private repo that gets accidentally made public for an hour. Indexers grab it forever.

In every one of those cases, the bytes leak without you in the room. Nobody is asking you for a second password. The recovered file is what the attacker has to work with.

That's the gap deniable encryption fits. The same encrypted seed-phrase backup decrypts to one wallet under one control file, and a different wallet under another. Both are valid. Both look like normal recovery. The bytes themselves don't tell the attacker which one is the holdings and which one is the dust wallet.

How it works with deny.sh

Encrypt your seed phrase at deny.sh/protect with two passwords. You enter your real seed and a plausible decoy seed (an old wallet with a small balance, a stale recovery phrase, anything that looks like it belongs to you but isn't where the holdings actually live). Out comes one ciphertext and two control files. The real control file + your passwords decrypts to the real seed. The decoy control file + your passwords decrypts to the decoy.

The real control file lives somewhere only you can reach: inside a photo (steganography), split across trusted parties (Shamir secret splitting), inside a vault that releases on a dead-man timer (dead man's switch). The decoy control file lives somewhere plausible: a notes app, a USB stick in a drawer, the backup folder a thief would actually look at.

When the bytes leak, the decoy is what the attacker tries first. They decrypt, they see a wallet with $150 and three transactions in 2024, they take it and walk away. Your real seed never appears in the recovered file. No forensic analysis can prove the decoy isn't the real thing because mathematically there is nothing to prove. Both decryptions are valid output of the same primitive.

What this isn't a defence against

This is the part the headline framing usually skips and we want to be plain about it.

Deniable encryption does not stop an adaptive adversary who already knows the tool exists in your life. If somebody is watching you, holds your subscription records, or otherwise has reason to believe you store seeds deniably, they will not stop at the first decoy. The cryptography keeps holding up. The behaviour around it does not. If your threat model is observed targeted pressure, deny.sh is not the answer.

It is also not a substitute for not having the file. If you are carrying something genuinely high-risk through a context where coercion is possible, the right move is still: don't carry it. Generate the wallet at the destination, walk through with nothing to hand over.

And the believability is on you. A wallet with $0 is not a credible decoy. A wallet with $150 and a year of small transactions is. The product gives you the cryptographic guarantee. The plausibility is your job.

Free. Browser-based. No signup.

Everything runs in your browser. No account. No server calls. Your seed phrase never leaves your device. The code is open source under AGPL-3.0. You can run 22 cryptographic tests yourself to verify the maths works: chi-squared analysis, entropy measurement, fuzz testing. Don't trust us. Verify. The whole flow takes about 60 seconds.

What to do right now

1. Go to deny.sh/protect
2. Click "Try with demo data first" to see how it works
3. Then do it for real with your actual seed phrase
4. Store the encrypted backup somewhere accessible
5. Hide the real control file somewhere only you know
6. Put the decoy control file somewhere an attacker would find it

That's it. The wrench is still its own problem. The leaks around it stop opening to your real wallet.