End-to-end encryption and key management

End-to-end encryption means only the two ends can read a message. The server in the middle carries ciphertext it cannot open. Most interview mistakes here come from mixing up which key does what.

• Asymmetric (a key pair). The public key is shared with everyone. The private key never leaves the device. Anyone can lock with the public key, and only the private key unlocks. It is slow, so use it for small things such as handing over a secret.
• Symmetric (one shared key). The same secret locks and unlocks. It is fast, so use it for the bulk work. The hard part is getting that secret to the other side safely.
• The usual pattern: asymmetric to share the secret, symmetric to do the bulk work.

• Alice encrypts with Bob public key. Only Bob private key can decrypt. The server stores public keys only.
• "Encrypt with my own private key" is a signature, not secrecy: anyone with your public key can open it. Signatures prove who sent a message. Encryption hides it.
• Bob may be offline when Alice starts the chat. The server therefore holds a few of Bob one-time public keys (prekeys) so Alice can start without Bob being online.

Encrypting separately for every device is 3,000 encryptions for one message in a group of 1,000 members with 3 devices each. Sender keys avoid that:

1. Each sender makes a symmetric sender key for the group.
2. They send it once to every member device, inside the normal one-to-one encrypted channel.
3. Each message is then encrypted once. The server fans out the same bytes and members decrypt with the sender key.
4. When a member leaves or joins, rotate the keys so the removed member cannot read anything new.

One shared key pair for the whole group does not work: asymmetric is slow for bulk data, and a removed member still holds the private key.

1. The device compresses the file, makes a random symmetric key and encrypts the file.
2. It uploads the ciphertext to object storage with a pre-signed URL.
3. The key and the file reference travel inside the normal encrypted message.
4. The recipient downloads the blob and decrypts it locally.

Because the server only sees ciphertext, it cannot compress, transcode, dedupe or virus-scan the file. All of that has to happen on the device before encrypting.