Security

Two separate paths, so the server never holds both the message and the key.

How it works

• AES-256-GCM. Your browser encrypts with the Web Crypto API using a fresh random key and a fresh random 96-bit IV. GCM also detects tampering.
• No server-side decryption. The server stores ciphertext only. The key is in the URL fragment, which browsers do not send in requests, and the page sets no-referrer so it is not leaked to other sites.
• One-time claim. Opening the link does not use it up. Only the explicit Break Seal action claims the message. The claim is a locked database transaction, so if two people try at once, only one receives the ciphertext, and it is erased in the same step.
• Expiry. You choose 10 minutes up to 7 days. The server sets the deadline and removes expired ciphertext, even if nobody opens the link.
• Multiple recipients. Each recipient gets an independent seal with its own key and expiry, so opening or leaking one link does not affect the others. Recipient names are never sent to the server.
• Shorter links. An optional shorter link uses a 128-bit key instead of 256-bit. It is still far beyond brute force; the standard link remains the default.
• Activity. The creator can see, in the tab that created the seal, when it was sealed and whether it has been opened, expired or destroyed. Only times are recorded. The service does not record who opened a seal, and it sends no notifications.
• Destroy Now. The creator can remove the message before it is opened, using a credential that is never part of the shared link.
• Optional passphrase. The passphrase is combined with the random link key in the browser (PBKDF2-HMAC-SHA-256, then HKDF). Both the link and the passphrase are required. A wrong passphrase is detected in the browser before any claim, so a typing mistake does not use up the seal.

Limitations

• Anyone with the full link can attempt to open the message. Share it only through a channel you trust, and prefer a passphrase sent separately for important secrets.
• After reveal, the recipient can copy or screenshot the secret. Once the plaintext is in the legitimate browser, no software can stop the recipient from recording it.
• Passphrase check trade-off. To avoid wasting a seal on a typo, the link carries a small confirmation value derived from the key. Someone who already holds the complete link could use it to guess the passphrase offline, limited only by the PBKDF2 cost. Choose a long, unique passphrase.
• Metadata is visible to the server. It sees that a seal exists, its approximate size, when it was created and its expiry, and standard connection details.
• Your device matters. Malware, malicious browser extensions or a compromised device can read a secret before it is encrypted or after it is shown. Messaging apps that store links also store the key.
• Trust in the code. The page's code comes from this server on each visit. As with any web app, you trust the site to serve unmodified code.

Found a vulnerability? Please report it responsibly using the contact on the Bidadari website.