A long password can resist guessing. AES-256-GCM can protect ciphertext. Neither can tell whether someone entered a password willingly or because another person demanded it. When the correct credentials arrive, decryption proceeds normally. Cryptographers call attacks against the person rather than the mathematics rubber-hose cryptanalysis. The name is grim; the limitation is real.
Decoy Mode offers an alternative opening: a second password reveals harmless content through the normal reading interface. It is a tool for a narrow situation, not a promise of safety under coercion. Personal safety comes before protecting a credential. No software setting guarantees that someone applying pressure will accept the explanation on screen.
What plausible deniability actually means
In an idealized deniable container, two valid keys lead to different, believable contents. Revealing one opening does not establish that another secret exists. The difficult property is not merely having two passwords; it is preventing an observer from proving that the second compartment is present.
VeraCrypt hidden volumes are a familiar example. Their protection depends on the format and on following the project's security precautions. Those properties cannot simply be transferred to a web application with a decoy password. Operating-system traces, copied files and observation of the setup can undermine a carefully constructed story.
Secure Link has a narrower goal: opening either branch uses the same reading screen, without a badge announcing a decoy. That interface behavior is useful, but it is not a proof of cryptographic indistinguishability. Treat the difference as part of the feature, not an inconvenient footnote.
How Decoy Mode works in Secure Link
Enable Decoy Mode when creating a password-protected link, then provide the real text, harmless alternative text and two different passwords. The recipient needs the link's encryption key plus either password. A password alone cannot unlock the outer container without the key carried in the URL fragment.
In the browser, PBKDF2-HMAC-SHA-256 derives a separate key from each password. The current decoy implementation uses one shared random salt and 100,000 iterations. Each text is independently encrypted with AES-256-GCM and a different initialization vector. Both encrypted branches are packed with random padding, then the entire container is encrypted again with a separate random link key.
That outer key lives after #, which browsers do not include in the HTTP request to the server. Split-link lets the sender deliver it separately. The server stores encrypted data; the browser decrypts it. A valid real password displays the secret, while the decoy password displays the alternative through the same interface.
Deletion needs a precise explanation. The current server assigns Decoy Mode a minimum of 3 views. Fetching the encrypted note consumes one view before password decryption. Successfully entering either password does not, by itself, delete a record with views remaining. The active Redis record disappears when its view budget is exhausted, its TTL expires or a manual burn occurs.
A successful decoy opening therefore does not guarantee immediate destruction of the real secret.
There are also observable implementation details. Server storage records that Decoy Mode is enabled. Padding obscures exact content length but does not make every payload identical, and decryption branches are not claimed to have indistinguishable timing. An operator, code analyst or observer of link creation may know more than somebody looking only at the reading screen.
Three rules for a believable decoy
- 1Match the context without giving away access. If the conversation concerns a sandbox API, a nonfunctional test-token-shaped value fits better than a shopping list. Never use a live credential as supposedly harmless cover. An old password is not harmless if it still works somewhere.
- 2Avoid a story the conversation directly contradicts. Announcing that the link contains a hidden production secret defeats the purpose. However, omitting that announcement proves nothing: the observer may know the feature exists or may have watched the note being created.
- 3Rehearse with invented data, not the working link. Understand which password opens which branch, where the fragment key is and how views are consumed. Create a fresh note for the actual handoff. Repeatedly checking the real link spends its budget and creates extra copies.
What it can help with — and what it cannot
| Situation | Potential benefit | Important limit |
|---|---|---|
| Someone demands a password for an unopened link | An alternative text can open normally | They may reject it; personal safety is not guaranteed |
| Someone watches only the reading screen | No separate decoy label is displayed | Server inspection, code analysis and timing are outside that claim |
| A keylogger runs on the sender's device | No dependable protection | Malware may capture both texts, passwords and the fragment key |
| Someone has copied ciphertext or plaintext | Server deletion limits future retrieval | It cannot erase downloaded files, screenshots or recordings |
Strong, distinct passwords still matter. Once an attacker has the container and its outer key, weak passwords may be tested offline. A compromised browser can capture content before encryption or after decryption. Neither problem is solved by adding an alternative message.
Choose the handoff, not just the feature
For important access, follow secure password-sharing practices and prefer a separate account with minimum permissions and a clear revocation path. Decoy Mode changes how a note can open; it does not manage the credential's lifetime in the destination system.
Start with the generator, choose a short TTL and rehearse using a disposable example. If your requirement is strictly one server retrieval, remember that the current decoy setting has a different view policy. Use it only when those limits fit your threat model.