End-to-End Encryption in the Cloud: Encryption Is Not All the Same

Added at 09/28/2025

For the average end user, it is often difficult to understand who exactly they are protecting their data from with a given encryption method. The specific needs play a major role in this.

Cloud applications are everywhere. This applies equally to home users and corporate users. The advantages are obvious: high availability and cost savings. Running your own servers is eliminated, installation effort is reduced, downtime is minimized by redundant systems provided by cloud operators, and your own data is accessible on all devices at any time.

On the other hand, there are cloud skeptics, and here too there are good arguments: a reliable internet connection is always required, switching between cloud services is often cumbersome, and – your own data is accessible to anyone at any time. The last statement may be exaggerated, but reports from the news world from the "Edward Snowden and NSA" era left many skeptical and uncertain. As an IT security expert, one can say: the skepticism is not unfounded.

“I have nothing to hide”

The statement “I have nothing to hide” is likely to divide opinions in the current IT era. This applies at least to the average private user, whereas for international companies, the general data protection laws of the respective country apply. Compliance with these laws in many companies goes so far that internal policies simply prohibit the use of cloud services for certain purposes (e.g., in Germany). In contrast, many individuals freely post photos or opinions on social networks, which can lead to job termination or legal action.

Ultimately, everyone must decide the value of their own privacy. As long as others are not affected or harmed, it remains a personal matter. Nevertheless, everyone should ask themselves how indifferent they are to the unwanted publication of their own data from certain cloud services. A simple example would be photos from a recent family celebration uploaded to the cloud just to share them easily with the whole family. Every person will give a different answer to this question. Other examples include cloud backups of the latest tax return, the purchase contract for a new car, or similar documents.

Encrypted, yes—but how?

Ensuring effective IT security is the main responsibility of the respective web and cloud service providers. There are various standards to follow, not just on paper but in practice. If users cannot rely on this, they additionally rely on encryption.

There are many types of encryption, and distinguishing between them is usually impossible for the average consumer. Some are used automatically without the user knowing. For example, HTTPS connections over TLS (formerly SSL) are used in online banking or shopping, ensuring that the data’s transport to the server is encrypted. Fortunately, this has become a quasi-standard, at least for important data. Many internet users are aware of this.

But what use is encrypted data transmission if hackers can still access it on the server through a security flaw? Another example: it still cannot be guaranteed that an email reaches its recipient exclusively via encrypted transport paths. Since major internet providers in Germany have enforced TLS as a secure connection between mail clients (desktop, mobile) and mail servers, email communication in Germany has become significantly safer, but this is not the case everywhere.

For email, there are at least two common solutions that have existed for quite a long time: S/MIME and PGP/OpenPGP. This is called end-to-end encryption. The sender encrypts the email, and only the recipient can decrypt it. This applies only to the message content, not the metadata (such as subject, email addresses, or timestamps), but at least the content is securely protected even over unencrypted transport paths. A digital signature additionally protects the email from tampering on potentially unprotected paths.

Data Encryption in the Cloud

Encrypting data in cloud services is much more difficult. Data processing occurs at the service provider, meaning true end-to-end encryption is nearly impossible unless explicitly supported by the provider.

I would like to define two specific classes of end-to-end encryption here:

Class 1) “True” End-to-End Encryption

Data is encrypted on the user's device. The key used for encryption is generated and stored locally. The key is not uploaded to the cloud. The user must ensure key backup to prevent data loss. The actual data is encrypted by the device before upload to the cloud, and decryption occurs only on the device. Current solutions are also called “Zero-Knowledge Cloud Encryption Solutions” or simlpy “Zero-Knowledge Storage”.

Class 2) Password-Based End-to-End Encryption

The service generates the encryption key directly or indirectly from the user’s password. The password is not stored; during login, the encryption key is recreated using secure hash calculations according to industry standards. Encryption and decryption occur in the application on the provider’s server. Since the password and data are encrypted only on the server, a functioning transport encryption (HTTPS) is required.

If you trust Class 2) encryption, the question of password loss becomes relevant. If the provider can recover your data in case of password loss, an additional encryption of your data with a master key or similar solution occurs. There are different implementation methods, which can significantly weaken the encryption strength.

Different Types of Cloud Services

When this article refers to cloud services, it naturally raises the question of which services are meant. An ERP or CRM system in the cloud works entirely differently from a simple file storage service. Accordingly, the possibilities for data encryption vary greatly.

As mentioned, ensuring encryption yourself can sometimes be difficult. This is especially true for applications that go beyond simple data storage and do not use encryption themselves. For ERP or CRM-type services, solutions like Lookout/CipherCloud exist. This is an appliance installed between the user and the cloud service used. Numerous cloud services are supported, including Salesforce. From a security perspective, the separation between the service provider and the encryption provider is positive. However, this is transparent encryption—Salesforce does not know about the encryption—so special procedures are required, which may not always be public. Additionally, not all database fields are always supported, and encryption solutions must explicitly support new and old fields for new cloud service versions.

For simple online storage or group-based online storage, the situation is better. Various solutions exist, such as Boxcryptor, the Crococrypt Product Family and others.

Security Features of Encryption

When considering using a cloud service, the question of long-term viability arises. For example, if you want to use online storage as a secure remote backup solution permanently, the encryption solution must also work long-term. If a cloud-based service is used for encryption, the long-term availability of decryption must not depend solely on that service. This also raises the question of willingness to pay, as costs and prices can change over the years.

Other considerations involve control and security features. One must ask who they want to protect their data from: private threats, industrial espionage, or even government agencies. Perhaps private users want protection from state institutions. Data loss due to carelessness, provider security flaws, and hacker attacks are further concerns. Trust in the service provider also matters. The resistance of Google or Apple to increasing demands from U.S. authorities for access to user accounts has recently been publicly discussed. Under what circumstances are my data accessed, who monitors it, and will I be informed?

With true Class 1) end-to-end encryption as defined above, the user retains full control. Even the service provider cannot restore the data on government request, as it is delivered encrypted. Of course, implementation effort is higher. Additional software must be installed, and key management is required across all devices.

A simple rule distinguishes the two classes: any application that advertises "encryption without installation" and is web-only is not true end-to-end encryption, but falls under Class 2).

Potential Attacks

As described, each user must decide the level of security they want for their data, even when encrypted. As an example, consider the case of “Lavabit.” Lavabit’s encryption fell under Class 2). It was a U.S.-based web service providing encrypted email. Public information indicates Edward Snowden used it. U.S. authorities demanded that the provider disclose the encryption and all user data, leading to the service being shut down by the operator.

Although Class 2) encryption is strong, there are dependencies on the service provider that can weaken it. Since the password is the basis for web-only encryption, it is the target of attacks. The server calculates the cryptographic keys, so the password is initially transmitted to the server. Successful attacks on HTTPS can break the encryption. Authorities could demand the server’s private keys from the operator. “Perfect Forward Secrecy” helps prevent later decryption of HTTPS traffic.

An alternative approach might be hashing the password in the user’s browser via JavaScript and transmitting only the derived key. However, the transmitted key then becomes the attack target. One could attempt to perform encryption entirely in JavaScript, but if an attacker can intercept HTTPS traffic, they could manipulate the JavaScript from the server.

Another attack vector for Class 2) services is server-side software manipulation. Whether forced by authorities or via server vulnerabilities exploited by hackers, this can steal user passwords and cryptographic keys. If the attacker already has server access, they can decrypt previously encrypted data.

It should be emphasized: without master or backup keys from the operator, attacks on Class 2) encryption require the user to log in again.

There are similar providers in Germany, e.g., Posteo.

Attacks on Class 1) encryption require access to the user’s active device. While not impossible, it is usually much harder.

Conclusion

Everyone must decide what data to place in the cloud and whether to use encryption. This applies equally to home users and companies. The method of encryption should be carefully considered. The classes defined in this article provide guidance.

For the average user, distinguishing the two classes can be difficult in practice due to increasing convergence of technologies and services. For example, PGP email encryption falls under Class 1). If a provider offers PGP in a webmail client, the private keys also reside on the provider’s server, placing the solution in Class 2).

Class 1) solutions are undoubtedly more complex to implement, but using a web-based encryption solution is far better than none.

About the Author

HissenIT is a highly specialized small company focused on IT security software development and consulting. Owner Computer Scientist Frank Hissen has over 20 years of experience in various roles as a security expert in development and consulting projects. He has worked mainly for large and medium-sized companies and specializes in applied and technical IT security work.