6.1 Encrypted Email Protocol
In this section, we describe the protocol that clients and the Zoom Mail Service server can use to encrypt and decrypt emails. The encryption format supports optional signatures over the emails: clients will sign all the emails they send to other Zoom Mail Service users using their device keys, while emails encrypted by the server (for example, those from external email providers) are not signed. For cryptographic purposes, an email consists of a sequence of opaque byte strings, which we call pieces; these may include the email body itself (which contains a MIME tree structure and email headers such as lists of “To” and “CC” email addresses) and attachments (we encrypt and treat pieces separately to allow, e.g., downloading attachments separately on demand). In addition, an email has a (possibly empty) BCC header string which lists the email addresses of any BCC recipients. The BCC header string is visible to the sender but not to recipients, and is used by the server for routing purposes. To encrypt an email for one or more Zoom Mail Service users, the sender or Zoom server uses the following procedure:
Encrypt each piece with a fresh uniformly random 32-byte key (different for each piece) using Cake-AES.9 Collect each key and the SHA-256 hash of each ciphertext10 into a list called the manifest. Then, encrypt the manifest itself using Cake-AES with another fresh uniformly random 32-byte key, called the shared symmetric key.
Compute the HMACSHA256 of the BCC header string with a random 32-byte commitment key to produce the BCC commitment.
Generate a random Curve25519 ephemeral sender private and public key.
For each recipient (including the sender themselves): (a) Resolve the recipient’s email address (using sigchains) into a recipient user ID and their email PUK (a public per-user Curve25519 key advertised in the recipient’s sigchain, derived as described in Section 3.4.1). Compute a Diffie-Hellman shared secret between this key and the ephemeral sender private key. (b) Using SHA-256, hash the following information into the recipient-associated digest: all user IDs and public keys used by the sender and recipient, the hash 9Cake-AES is a custom encryption format built on top of AES-GCM. Its ciphertexts commit to both the key and plaintext used to produce them, and it supports random-access decryption and large ciphertext sizes. See Appendix C for details. 10As an optimization, when forwarding or replying to an email containing an attachment, clients reuse the same ciphertext, key and hash related to the attachment in the new email to avoid having to download, re-encrypt and re-upload the attachment. The additional leakage is acceptable, given that the server could likely figure that the attachment is the same based on context and attachment size.
of the manifest ciphertext, the BCC commitment, and other context such as the version number. The BCC commitment is only used by the sender to verify and display the BCC header string in their own outbox. (c) If the sender is a Zoom Mail Service user, then using Ed25519, sign this hash with the sender’s private device signing key. (If the Zoom server is encrypting an email, omit this signature.) (d) Using HMACSHA256, derive a key from the recipient-associated digest and the Diffie-Hellman shared secret. (e) Using XChaCha20-Poly1305 with this key, encrypt the shared symmetric key and, if it exists, the signature over the recipient-associated digest to produce a recipient box ciphertext. 5. Sign the list of recipient-associated digests (including BCC recipients) with the sender’s private device signing key to produce the recipient list signature. The recipient list signature is only used by the sender’s client to verify the email’s recipients in their own outbox, and is not sent to recipients. 6. Send all ciphertexts, the BCC commitment and key, the recipient list signature, and the ephemeral sender public key to the server, along with the BCC header string and the other headers needed to route the email. There are several use cases where the sender needs to give the server access to the email contents, which we detail below. To handle these cases, the sender follows the above procedure except that they create an additional recipient box using a fresh random public key as the recipient key and reveal the corresponding secret key to the server. This preserves the authenticity guarantees of E2E encryption for the other recipients, and also allows the sender to upload the encrypted email body and any attachments only once. In addition, the sender sets a flag in the email manifest indicating that the email is not end-to-end encrypted, which clients use to display the encryption type in the UI.11 When the server receives an email from a sender, it checks that the sender is logged in to an active device. It then puts a copy of the email in each recipient’s inbox and a copy in the sender’s “sent” folder. Each recipient’s copy only contains their own recipient box ciphertext and, except for the sender’s copy, doesn’t contain the BCC header string, the BCC commitment key, or the recipient list signature. Although the sender’s copy omits other recipients’ box ciphertexts, it must retain the user ID and PUK generation of all other recipients to allow the recipient list signature to be verified. If there are any external recipients (such that the email is no longer E2EE), the server is able to decrypt the email and forward it to the external recipients. Upon receipt of an email, the recipient follows these steps. Note that this includes senders viewing emails from their “sent” folder.
If a signature is present, load the signer’s user sigchain to check that the sender signing key is valid. If the key is not the signing key of some device on the sigchain, decryption returns an error. Clients allow messages signed by revoked devices because the email could have been legitimately sent from the device before it was revoked, and rely on Zoom servers to prevent revoked devices from sending further messages. In future releases, messages signed by revoked devices will be highlighted in the user interface, so that users can be especially cautious. (Note that we allow unsigned messages even if the sender’s email address is known to be using Zoom Mail Service: for example, the sender might have sent this specific email from a different email service before migrating their address to Zoom Mail Service. Such emails are indicated as not E2E-encrypted.)
If the email being viewed was sent by the current user, assert that the BCC header string, the BCC commitment key, and the recipient list signature are all present. Verify the commitment, then recompute all recipient-associated digests and verify the signature. The BCC header and recipient list are now trusted and can be displayed in the UI.
Independently compute the recipient-associated digest and the Diffie-Hellman share between the recipient’s key and the sender’s ephemeral public key. Using that hash and share, derive the key to decrypt the recipient box ciphertext and get the signature over the recipient-associated digest and shared symmetric key. Verify the signature.
Using the shared symmetric key, decrypt the manifest ciphertext to get a list of piece keys and piece ciphertext hashes.
On demand, fetch each piece ciphertext, verify its hash, and decrypt it with its piece key. Recipients do not receive or verify public keys for other recipients, but do see their email addresses in the “To” and “CC” headers.
Last updated