Some secret-sharing tools encrypt a secret on their server. Others use end-to-end encryption in secret sharing: the secret is encrypted in your browser before it is sent. The difference decides who could read your secret if the server were compromised, so it is worth understanding.
Your browser sends the secret over HTTPS, and the server encrypts it before storing it. This protects the stored data, but the server briefly handles the readable secret and holds the keys, so a compromise of the server could expose it.
Your browser creates a random key and encrypts the secret before anything is sent. The server receives only ciphertext, which it cannot read. The recipient’s browser decrypts it with the key from the link.
The key is placed in the fragment of the link, the part after the # sign. By design, browsers do not include the fragment in the requests they send, so the key does not reach the server in normal use. Anyone with the full link can decrypt, so the link itself is the secret and should be sent carefully.
A passphrase adds a second ingredient. A good design stretches it into two values: one that helps form the encryption key, and one used only as a proof the server can check. Then the server can limit guesses without ever being able to decrypt.
Think of the secret as a letter in a locked box. With server-side encryption, you hand the open letter to the post office, which locks it in its own box and promises to keep the key safe. With end-to-end encryption, you lock the box yourself and send only the locked box. The post office carries it but never has the key, and you give the key to the recipient separately.
In secret sharing, the “key” is a long random string in the link, and the “locked box” is the encrypted text stored on the server.
With end-to-end encryption the secret is encrypted in the sender’s browser and only decrypted by the recipient, so the server stores ciphertext it cannot read. With server-side encryption the server performs the encryption and holds the keys.
In normal use, no. The key sits after the # sign in the link, and browsers do not send that part to the server.
No. The website delivers the encryption code, so you rely on it serving honest code. If that is not acceptable for your threat model, use a tool you host yourself or run locally.
See exactly what SecureVoult encrypts, and what it does not. Read how SecureVoult protects secrets. By default, SecureVoult shows a secret once and then deletes it, so nothing is left behind in email, chat or tickets.
Keep reading: