About Secret Sender

Secret Sender lets you share a password, API key, or other sensitive text with someone through a one-time link. Once the recipient reads the secret, it is permanently destroyed. If nobody reads it before it expires, it is destroyed anyway.

Why use this instead of email or chat?

Messages in email inboxes, chat logs, and backups tend to live forever. A secret here has a short lifetime, can only be read once, and the sender gets confirmation of exactly when and from where it was read.

How it works

• You type a secret in your browser. It is encrypted locally using AES-GCM with a 256-bit key derived from a freshly generated random password.
• Only the ciphertext, expiration, a random IV, a random salt, and optional allowed IP are sent to the server. The plaintext and the password never leave your browser, except by your own actions.
• You share the link and the password with the recipient through two different channels (for example, link by email, password by text message).
• The recipient opens the link, enters the password, and the ciphertext will retrieved and decrypted in their browser.
• The server marks the secret as read, and discards the stored cyphertext in a single atomic operation, so it can never be read again.

What the server can and cannot see

• The server stores the ciphertext, IV, salt, expiration, and optional allowed IP. It cannot decrypt the secret because it never receives the password.
• If the server is compromised, only encrypted blobs are available. Without the password, the data is useless.
• When the recipient reads the secret, the server records the time, their IP address, and their user agent so the sender can verify the read.
• The server cannot see the success of the decryption after retrieval.

Protections in place

• Read-once enforcement: retrieval uses an atomic database update so a secret cannot be read twice, even under concurrent requests.
• Expiration: you choose how long the secret lives. Expired ciphertext is wiped automatically every 5 minutes.
• Optional IP restriction: you can require the recipient to be at a specific IP address.
• Rate limiting on all endpoints to slow down enumeration and brute-force attempts.
• Wrong-password attempts still consume the secret. There is no way to retry, which prevents an attacker who intercepts the link from guessing the password.

Limitations you should know about

• End-to-end encryption only protects the secret in transit and at rest. It cannot protect against a compromised browser, a malicious recipient, or someone who obtains both the link and the password.
• Share the link and the password through different channels. Sending both in the same email or chat removes most of the benefit of this tool.
• A failed decryption of the secret will still show as a successful read in the status page.