What Is a Duress PIN? How a Decoy Unlock Protects You Under Coercion
The strongest encryption in the world has a single, stubborn weakness: it cannot tell the difference between you typing your passphrase freely and you typing it with someone’s hand on the back of your neck. A 256-bit key derived through a memory-hard function might take a billion-dollar cluster centuries to brute-force, but it takes a border agent about ninety seconds to say “unlock it or you don’t board the plane.” Cryptographers gave this failure mode a darkly funny name — rubber-hose cryptanalysis — and the canonical illustration is XKCD #538, where the attacker skips the million-dollar crypto cluster entirely in favor of a $5 wrench. A duress PIN is the most practical software answer we have to that wrench: a second, fake unlock code that opens a believable decoy version of your device while the real data stays sealed or is destroyed. It does not make you immune to coercion. It changes what coercion gets the adversary.
The wrench problem is the real problem
Most security writing obsesses over the math — key lengths, lattice hardness, the forward secrecy guarantees of the Double Ratchet. That work matters, and it is genuinely hard: the Signal Double Ratchet specification exists precisely so that compromising one message key does not unravel a conversation. But none of it touches the scenario where the adversary stops attacking the cipher and starts attacking you.
This is not a fringe case. It is the median case for the people who most need secure messaging. A journalist crossing a border. An activist detained at a protest. A domestic-violence survivor whose abuser demands their phone. In each, the threat is not a quantum computer — it is a human being with leverage, asking you to type six digits. The EFF’s work on border device searches documents how routine warrantless “unlock it” demands have become at U.S. ports of entry, where the so-called border-search exception has historically let agents inspect devices without probable cause.
Cryptography assumes the key holder is a free agent. Coercion breaks that assumption. Everything downstream of it has to be designed for a key holder who is not free.
So the design question is not “how do we keep the password secret?” — under a wrench, you can’t. The question is: when you are forced to comply, what does compliance reveal?
What a duress PIN actually is
A duress PIN (sometimes called a decoy PIN, panic PIN, or fake unlock) is a second valid credential that produces a different outcome than your real one. You set both in advance. Your real PIN opens your real data. Your duress PIN, entered at the same lock screen, makes the app appear to unlock normally — but what loads is not your life. Depending on configuration, it is an empty account, a curated set of innocuous conversations, or a sanitized subset of your data. To the person watching over your shoulder, nothing looks wrong. There was no error, no second prompt, no “access denied.” The app opened. You complied.
The mechanism is rooted in how a good encryption scheme derives keys. In a system where the PIN is the key — not a password checked against a stored hash, but the sole input to a key-derivation function — there is no central place that decides “this PIN is right and this one is wrong.” Each PIN simply derives a different key, and each key unlocks a different encrypted blob. RVNT’s PIN authentication works this way: your PIN feeds Argon2id (64 MB memory cost, deliberately slow) to produce the key for the local SQLCipher database. The duress PIN derives an entirely separate key for an entirely separate, pre-staged decoy store. Neither “knows” about the other. There is no flag in the database saying this is the fake one — which matters, because a flag is something forensics can find.
This is a cousin of deniable encryption: the idea, explored in tools like the old TrueCrypt hidden-volume design, that ciphertext should be able to decrypt to more than one plausible plaintext, so that revealing a key does not prove you revealed the key. A duress PIN brings that property to the lock screen instead of the disk image.
What makes a decoy believable
An empty vault is suspicious. A border agent who has searched ten thousand phones knows that nobody’s messaging app is genuinely empty. A blank account screams you wiped this for me, which can escalate the situation rather than defuse it. So the decoy has to be lived-in.
A credible decoy vault is generated, not improvised in the moment. The realistic version contains:
| Property | Why it matters |
|---|---|
| Several contacts with ordinary names | One contact looks staged; a small social circle looks real |
| Dozens of mundane messages | Grocery lists, “running 10 min late,” family check-ins |
| Timestamps spread over weeks | A burst of messages all dated yesterday reveals staging |
| Culturally appropriate content | A decoy that doesn’t fit your life is its own tell |
| No conspicuous gaps | An app with one conversation and no history reads as fake |
RVNT’s duress mode pre-stages exactly this kind of decoy — contacts, mundane message threads, timestamps distributed across the prior two weeks — encrypted under a key derived from the duress PIN, not the real one. The goal is a vault that survives a glance and a scroll, because a glance and a scroll is usually all you get.
Decoy unlock versus panic wipe — they solve different problems
People conflate these two, but they answer different questions, and choosing wrong can hurt you.
A decoy unlock preserves your real data behind the scenes while showing the adversary something harmless. You keep your messages; you just don’t show them. The bet is on deception.
A panic wipe destroys the cryptographic material outright. RVNT’s panic mode executes a staged cryptographic self-destruct: it invalidates hardware-backed keys (on Apple Silicon, Secure Enclave key invalidation happens first and is irreversible at the silicon level), then tears down the encrypted database, overwrites key files, and clears the media cache. After it runs, the data is gone — not hidden, gone. The bet is on destruction: even a forensic lab with the device in hand finds AES-256 ciphertext with no surviving key, which is indistinguishable from random noise.
The two can be combined. A duress PIN can be configured to both destroy the real data and present a decoy — so the adversary sees a normal-looking app, and even if they later image the disk and somehow defeat the decoy, the real keys no longer exist to recover. That combination is the strongest configuration, and it is also the most consequential, because it is one-way.
Panic mode is irreversible by design. There is no undo, no backup that survives, no recovery path. Treat the duress-plus-wipe option the way you’d treat pulling a fire alarm: real, deliberate, and not a thing you test casually with your only copy of the data.
Decoy-only (no wipe) keeps your data but stakes everything on the adversary believing the decoy. Wipe-only (no decoy) guarantees they get nothing real but produces a conspicuously empty app. There is no universally correct choice — it depends on whether your threat is discovery of specific content or the mere fact that you’re hiding something.
Where a duress PIN fails — honestly
This is the part most vendors skip. A duress PIN is a real defense with real, hard limits, and using it without understanding them is worse than not having it.
Forensic imaging defeats deception, not destruction. If the adversary does not just glance at your phone but takes a full disk image and analyzes it offline, a decoy-only setup is in trouble. Investigators can look for a second encrypted region, unusual free-space patterns, or storage that’s inconsistent with a “fresh” account. Deniable-volume schemes have been studied for exactly these weaknesses for two decades. This is why pairing the decoy with genuine key destruction matters: forensics cannot recover a key that no longer exists, but it absolutely can notice a vault that’s hiding a second vault.
An adversary who knows the feature exists can demand the other PIN. This is the deepest limitation, and our own threat model states it plainly under “rubber hose cryptanalysis”: a sophisticated adversary may detect the duress scenario through empty or decoy conversations and behavioral cues. If your interrogator knows RVNT ships a duress PIN — and security tools are open about their features, so they can — they can simply say “now give me the real one.” Plausible deniability degrades the moment the existence of a hidden mode is common knowledge. The wrench, as always, gets the last word.
SSDs don’t forget cleanly. Even a wipe has limits against a well-resourced lab. Flash memory uses wear leveling, so overwritten data can linger in unmapped blocks. RVNT’s defense is layered — destroy the key first, then overwrite, then issue TRIM hints — but no software wipe is 100% against someone willing to desolder NAND chips. The saving grace is the same as everywhere else: recovered ciphertext fragments are useless without the key, which is why hardware-backed key destruction is the load-bearing step.
Behavior leaks. The software can hide your data; it cannot hide your sweating, your hesitation, or the fact that you typed a different number of digits than usual. Duress features assume a calm operator. Reality rarely supplies one.
And one legal wrinkle worth knowing: in several U.S. cases, courts have found that compelling a memorized passcode implicates Fifth Amendment protection against self-incrimination, while a fingerprint or face scan often does not — the Indiana Supreme Court’s decision in Seo v. State treated unlocking as a form of testimony. A PIN you can refuse to disclose is, in some jurisdictions, on firmer legal ground than biometrics that can be pressed onto a sensor while you sleep. That’s a reason to favor a PIN over Face ID where your threat model includes legal compulsion — and a reason a duress PIN has somewhere to live in the first place.
Where this sits in a real defense
A duress PIN is one layer, not a strategy. Underneath it, RVNT’s content protection is built to be useless to an adversary who doesn’t have you in a room: hybrid post-quantum key exchange (X25519 + ML-KEM-768, the latter standardized as FIPS 203 in August 2024) so that intercepted traffic resists future quantum decryption, the Double Ratchet for forward secrecy, sealed sender and a mixnet to starve traffic analysis of metadata. The duress PIN exists for the one threat all of that can’t touch: the moment you are physically compelled to open the lock yourself.
If your situation involves crossing a border, the duress PIN is only part of a larger checklist — minimize what’s on the device, understand your rights, and plan for the search rather than improvise during it; we walk through that in crossing a border with your phone.
RVNT ships a real, working duress decoy on both desktop and iOS today — not a “coming soon” toggle. It is also pre-release software that has not yet undergone a formal third-party security audit, and a duress PIN does not protect you against a compromised device, a forensic lab with unlimited time, or an adversary who knows to ask twice. What it does is narrow and honest: it changes the outcome of compliance, so that handing over your phone hands over a life that isn’t yours. That is not invulnerability. In a world of $5 wrenches, it might be the most you can ask software to do.
Keep reading
All posts →-
Cryptographic Deniability: Why an Encrypted Message Can't Be Proven in Court
How cryptographic deniability lets an encrypted chat authenticate its participants yet prove nothing to a third party — the OTR origin, Signal's offline deniability, and the legal caveat.
9 min read -
Panic Mode and Remote Wipe: Surviving Device Seizure
How cryptographic self-destruct destroys keys to make ciphertext noise instantly, why crypto-erase beats file deletion, the Cellebrite/GrayKey threat, and honest limits.
9 min read -
Prekey Bundles: How Encrypted Chat Works When You're Offline
How prekey bundles let encrypted chat work when the recipient is offline: what they contain, how a sender derives a shared secret alone, and the key-substitution risk.
9 min read -
What Is a Mixnet? Mix Networks vs Tor for Metadata Privacy
A mixnet batches, reorders, and delays encrypted traffic with cover noise to defeat timing analysis. How mix networks differ from Tor, and how RVNT layers both.
9 min read -
X3DH, Explained: The Handshake Behind Asynchronous Encryption
How X3DH lets two people share an encryption key when one is offline — the four Diffie-Hellman operations, what each provides, and the post-quantum upgrade.
9 min read -
The Anthropic Recall: How Centralized AI Threatens Decentralized Privacy
A breakdown of today's US government export control directive targeting Anthropic, the vulnerabilities of centralized AI architectures, and why decentralized, sovereign communications are vital.
5 min read -
Sealed Sender: Hiding Who Talks to Whom
A technical deep-dive on RVNT's sealed sender: how encrypting the sender certificate to the recipient hides the from-to routing pair, and how forgery, replay, and abuse are handled.
9 min read -
Chat Control, Explained: The EU's Fight Over Scanning Your Messages
EU Chat Control explained: what the CSA Regulation proposes, why client-side scanning breaks end-to-end encryption, the 2025-2026 timeline, and its current status.
11 min read