Sends are a secure and ephemeral mechanism for transmitting sensitive information to anyone, include plaintext and files. As the About Send article notes, Sends are end-to-end encrypted, meaning that encryption (described below) and decryption occur client-side. When you create a Send:
A new 128-bit secret key is generated for the Send.
Using HKDF-SHA256, a 512-bit encryption key is derived from the secret key.
The derived key is used to AES-256 encrypt the send, including its file/text data and metadata (name, filename, notes, and more).
The encrypted Send is uploaded to Bitwarden servers, including a unique ID that Bitwarden uses to identify the Send for decryption but not including the encryption key.
Sends are decrypted by opening the Send link, which is constructed from a unique Send ID and the derived encryption key:
This has several components:
The anchor/fragment/hash contains the send id and send key of the URL.
The anchor/fragment/hash is not sent to the server. This information is used locally within the browser to identity and decrypt the send.
When you access a Send link:
The web browser requests a Send access page from Bitwarden servers.
Bitwarden servers return the Send access page as a web vault client.
The web vault client locally parses the URL fragment containing the Send ID and encryption key.
The web vault client requests data from the server based on the parsed Send ID. The encryption key is never included in network requests.
Bitwarden servers return the encrypted Send to the web vault client.
The web vault client locally decrypts the Send using the encryption key.
If your Send is password-protected, decryption of the Send will be blocked by authentication. The server validates the password and only returns the Send if the password is correct. This should not be confused with the password being used for decryption.
When transmitting a Bitwarden Send link, there are optional steps you can take for additional security:
Add a password to the Send and share the password via a separate channel.
Send the link without the key (everything before the last forward slash) and send the key via a separate channel.
Leverage both of the above options.
When reassembling a Send URL, be sure to include both the Send ID and the encryption key.