What is End-to-End Encrypted Transmission

End-to-end encryption is a method of data transmission where no one other than the original sender and the target device can read the data. The original sending device and the target device are the "ends" in the "end-to-end" chain.

Intermediate servers or devices can only see the encrypted bytes (or ciphertext), which appear as random noise. No party or third-party service can reconstruct or restore the original data.

The Importance of End-to-End Encryption

End-to-end encryption ensures that services cannot read or process data in a centralized manner on their servers. This eliminates the risk of large-scale data breaches and reduces the value to potential attackers.

Many services only encrypt data that is "in transit" or "at rest", meaning the service itself can read and process the data at any time. This means that anyone with access to the service's internal systems can access the data. Over the past decade, we have all heard about data breach incidents at some of the largest companies. Whenever data is stored centrally or together, it is a high-risk, high-value attack target.

The Difference Between End-to-End Encryption and "In Transit" or "At Rest" Encryption

When data is encrypted end-to-end and transmitted to a service, the service cannot read or process the data. Only the original device and the final target device can decrypt, read, and process the transmitted data. This is much more private and secure compared to "in transit" or "at rest" encryption.

Services that encrypt data that is "in transit" or "at rest" can only prevent unauthorized third parties from reading or processing data. The service itself or anyone with access to the service's internal systems can read and process the unencrypted data at any time.

Examples of End-to-End Encryption

Consider a simplified example of sending a photo from one smartphone (A) to another smartphone (B) using DROP.space:

1. Smartphone A accesses DROP.space, creating a new empty space and a shareable space link. The secret key of the shareable link is only known by smartphone A and is not sent to the remote server.
2. Smartphone A adds a photo. It is fully encrypted on the device, and then the encrypted bytes (ciphertext) are transmitted to the remote server for persistence. The remote server cannot see or reconstruct the original photo from the ciphertext.
3. Smartphone A shares the shareable space link with smartphone B, similar to the link DROP.space/s/abcd#1234; the part after the # (fragment or hash) is a "secret key" known only by smartphones A and B.
4. The browser is instructed not to send the part after the # to the server. Therefore, the servers of DROP.space will never see or know the secret key.
5. Smartphone B opens the link, connects to DROP.space/s/abcd, and downloads the encrypted version of the photo.
6. Now, smartphone B can use the secret key #1234 of the shareable space link to decrypt the photo and display it in the browser.

At any time, neither DROP.space nor the servers of the DROP.space team know or need to know the secret key or the unencrypted information of the original photo. Secure sharing in a privacy-protected manner does not need to be complicated.

Encryption Types Used by DROP.space

• DROP.space uses SSL/TLS for all data in transit.
• Data stored in our RDBMS is encrypted both at rest and in transit.
• All end-to-end encryption operations use the libsodium library. The name and content of each project are encrypted with XSalsa20-Poly1305 and a secret key.
• Each file is encrypted in ≈4MB blocks using the secret stream algorithm ChaCha20Poly1305-IETF of libsodium.
• Different entities within DROP.space have a pair of public and private keys for encryption and/or signing. Encryption key pairs use X25519 and XSalsa20-Poly1305. Signing key pairs use Ed25519.
• Each device generates two pairs of public and private keys, one for encryption and one for signing, and the private keys never leave the device.
• Each space has a pair of public and private keys for encrypting and sealing the secret key of each project.
• When a device is added to a space, the private key of the space is encrypted with the public key of the device and sent to that device.
• When a project is added to a space, the secret key of the project is encrypted with the public key of the space, and then the ciphertext is shared with all members of the space.
• Each shareable