Send encryption (#492)

* send encyrption article, first cut

* links

* edits from the team

_articles/faqs/send-faqs.md

@@ -5,7 +5,7 @@ categories: [send]
 featured: true
 popular: false
 tags: []
-order: 08
+order: 09
 ---
 
 ### Q: Why can't I create a file Send?

_articles/send/about-send.md

@@ -8,11 +8,11 @@ tags: [bitwarden send, send, about send, ephemeral sharing]
 order: 01
 ---
 
-## What is Send? 
+## What is Send?
 
 Bitwarden Send is a secure and ephemeral way to transmit sensitive information to **anyone**. Sends can include plaintext or file attachments up to 100 MB. Every Send is assigned a randomly generated and secure link, which can be [shared with anyone]({% link _articles/send/receive-send.md %}) (including those who *do not* have Bitwarden accounts) via text, email, or whatever communication channel you prefer. Every Send is:
 
-- **End-to-end Encrypted**: Data in a Send is encrypted on creation, and only decrypted when a recipient opens the Send link. The contents of a Send are stored **encrypted** in Bitwarden systems, just like a traditional Vault item. The link generated for each send doesn't contain any data related to the Send's contents, so it's safe to share over intermediary communications services without exposing information to Bitwarden or any used intermediary services.
+- **End-to-end Encrypted**: Data in a Send is [encrypted]({{site.baseurl}}/articles/send-encryption/#send-encryption) on creation, and only [decrypted]({{site.baseurl}}/articles/send-encryption/#send-decryption) when a recipient opens the Send link. The contents of a Send are stored **encrypted** in Bitwarden systems, just like a traditional Vault item. The link generated for each send doesn't contain any data related to the Send's contents, so it's safe to share over intermediary communications services without exposing information to Bitwarden or any used intermediary services.
 
 - **Dynamically Ephemeral**: Sends are designed for ephemeral sharing, so every [Send that you create]({% link _articles/send/create-send.md %}) will have a specified [lifespan]({% link _articles/send/send-lifespan.md %}) (*max 31 days*) that can be configured using pre-set options or a custom timestamp for down-to-the-minute specification. When its deletion date is reached, the Send and its contents will be completely purged from Bitwarden systems. Using additional options like [Expiration Date]({{site.baseurl}}/article/send-lifespan/#expiration-date) and [Maximum Access Count]({{site.baseurl}}/article/send-lifespan/#maximum-access-count), you can ensure that access to recipients is terminated according to your needs.
 

_articles/send/send-encryption.md

@@ -0,0 +1,37 @@
+---
+layout: article
+title: Send Encryption
+categories: [send]
+featured: true
+popular: false
+tags: [bitwarden send, send, about send, ephemeral sharing]
+order: 07
+---
+
+## Send Encryption
+
+Sends are a secure and ephemeral mechanism for transmitting sensitive information to anyone, include plaintext and files. As the [About Send]({% link _articles/send/about-send.md %}) article notes, Sends are **end-to-end encrypted**, meaning that encryption (*described below*) and decryption occur client-side. When you create a Send:
+
+1. A new 128-bit secret key is generated for the Send.
+2. Using HKDF-SHA256, a 512-bit encryption key is derived from the secret key.
+3. The derived key is used to AES-256 encrypt the Send, including its file/text data and metadata (Name, Filename, Notes, etc.).
+
+   {% callout success %}Any [password]({{site.baseurl}}/article/send-privacy/#send-passwords) used to protect a Send **is not involved in encryption** and decryption of a Send. Passwords are purely an authentication method, however password-protected Sends will be [blocked from decrypting](#send-decryption) until password authentication is successful.{% endcallout %}
+4. The encrypted Send is uploaded to Bitwarden servers, including a unique Send ID that Bitwarden uses to [identify the Send for decryption](#send-decryption) but **not including** the encryption key.
+
+## Send Decryption
+
+Sends are decrypted by opening the [Send link]({% link _articles/send/receive-send.md %}), which are constructed from a unique Send ID and the derived encryption key:
+
+`https://vault.bitwarden.com/#/send/send_id/encryption_key`
+
+When you access a Send link:
+
+1. The web browser requests a Send access page from Bitwarden servers.
+2. Bitwarden servers return the Send access page as a Web Vault client.
+3. The Web Vault client locally parses the URL fragment containing the Send ID and encryption key.
+4. The Web Vault client requests data from the server based on the parsed Send ID. The encryption key is **never** included in network requests.
+5. Bitwarden servers return the encrypted Send to the Web Vault client.
+6. The Web Vault client locally decrypts the Send using the encryption key.
+
+   {% callout success %}If your send is [password-protected]({{site.baseurl}}/article/send-privacy/#send-passwords), decryption of the Send will be **blocked by authentication**, however this should not be confused with the password being used for decryption.{% endcallout %}

_articles/send/send-hosting.md

@@ -5,7 +5,7 @@ categories: [send]
 featured: true
 popular: false
 tags: []
-order: 07
+order: 08
 ---
 
 Once you [update your instance]({% link _articles/hosting/updating-on-premise.md %}), most implementations will be already setup to begin [using Send]({% link _articles/send/create-send.md %}). An exception to this is if you're using a non-default **mapped volume for attachment storage**.