End-to-End Encryption (E2EE) for Dropbox, Google Drive and Co.

Summary: End-to-end encryption is when only the receiver and sender can decrypt the content. The platform provider must not have access to the content in plain text at any time - regardless of whether it is a chat app or cloud storage.

At Boxcryptor we have specialized in the secure use of cloud storage. If you are making use of a cloud storage for saving your files, you most likely want to rest assured that those files remain protected within the cloud at all times - no matter whether those files are important documents or the pictures you have taken during your last holiday trip. No-one other than you should be able to gain access to these files.

The cloud storage providers offer some sort of protection (against unauthorized access). Still, you as a user of such services would sleep better at night knowing that your most valuable files do not exist in their legible form outside of your own, personal device (i.e. on a server or during the transmission process to a server).

This is only possible with secure end-to-end encryption. In this article, we would like to introduce end-to-end encryption to you and explain its’ functionality to some extent.

What is End-to-End Encryption (E2EE)?

E2EE is truly accomplished when a message (or file) is encrypted by the sender and can only be decrypted by the intended receiver. The file has to remain encrypted during the whole process of transmission. To ensure that the message or file remains encrypted during transmission, the key for encrypting and decrypting the message may only be possessed by the sender and the receiver. This is a crucial aspect for true end-to-end encryption.

• If the key for encryption is saved on the server forwarding the message this is no true end-to-end-encryption.

• If the key can be deciphered by a server or be prompted in any other way, it is no true end-to-end encryption.

The largest difficulty for true E2EE in reality is how the key for decryption is provided to the receiver. This is easy if the sender and the receiver can meet in person to exchange keys, previous to sending a message or file - but in reality, this is a very rare scenario.

Therefore, in practice, sender and receiver usually resort back to a public key infrastructure. This means that the receiver creates a public key. With this public key, it is only possible to encrypt, not to decrypt. The sender may now encrypt the message with this public key and send the encrypted message to the receiver. The receiver is the only one in possession of the private key necessary for decrypting the message => This form of encryption is classified as end-to-end encryption.

The issue of exchanging the key is solved by this public key infrastructure, but this produces other issues: How does the sender know for sure that the public key is truly owned by the receiver and does not belong to someone else, pretending to be the receiver?
This is a difficult problem to handle and cannot be dealt with without a central entity that is managing the attribution of public key and (true) receiver. Boxcryptor represents such a central entity, assigning public keys to receivers. This is the reason why our users have to create and register a personalized account.

How does end-to-end encryption work?

The message or file is usually made illegible on the device of the sender by applying hybrid encryption. Hybrid encryption is used for reasons of efficiency and implies that the message is encrypted with a symmetrical key (e.g. AES). The utilized AES-key is then encrypted with the public key of the receiver. After that, the encrypted message, as well as the encrypted AES-key is transmitted to the receiver. The receiver then decrypts the AES-key with their private key and subsequently decrypts the message with the AES-key received together with the message.

Most frequent fields of application

E2EE may be applied when a message is supposed to be transmitted in encrypted form and the message does not need to be analyzed during the transmission process. There is no “typical” field of application, but it is frequently used to encrypt chats and messages of any kind, file transfer processes, and backups.

Reasons for end-to-end encryption

Privacy and business secrets are equally worthy of protection. Unfortunately, there are many different players involved in cloud storage. In man-in-the-middle attacks, attackers focus on data in transit, intelligence services try to gain insight, and authorities are given extensive powers of access to data thanks to the CLOUD Act and EARN IT Act. And the cloud storage providers are trying to lull their users into a false sense of security with spongy worded terms and conditions, while at the same time they themselves analyze the data and examine it for patterns. Fortunately, end-to-end encryption software offers a remedy here.

How is Boxcryptor implementing end-to-end encryption?

The Boxcryptor keys are generated on a local device of the user. This includes the public and the private key. Those keys are uploaded to our server illegible for us and third parties. The keys are encrypted with the password of the user to which we do not have access.

By doing so, we achieve two major advantages:

• Firstly, the encryption may be started by the user from every device connected to the internet, without having to physically carry the encryption keys everywhere, due to our servers being able to provide those keys upon request.
• Furthermore, we at Boxcryptor are not able to access the users’ keys at any time, due to them being encrypted with the users’ password – this is a prerequisite for E2EE.

When a user shares a file, Boxcryptor initially gets the public key of the user, with whom the file is supposed to be shared, from the server. The public key is no secret since it is used for encrypting only, not for decrypting. Therefore, the public key is stored in clear text on our server. The AES-key for decrypting the file is now encrypted with the public key of the receiving user. After that, the encrypted AES-key (used for encrypting the message) it is attached to the encrypted message.

The synchronization software of the respective cloud-storage provider then synchronizes the encrypted file (including the encrypted AES-key) to the device of the receiver, where first of all the AES-key is decrypted, using the private key of the receiver and subsequently the file itself.

The encryption process described in this article is a simplified depiction of the complete process, since there are too many aspects of importance, with regard to the process. For more detailed information about our encryption process, we provide a technical overview on our Boxcryptor website.