Some platforms claim end-to-end encryption, but few deliver it.
This blog explores what end‑to‑end encryption really means, why it matters, where some services fall short, and how Hexiosec Transfer achieves it by design.
Many online tools strive to make it easy to share files and data, but this often comes at the expense of privacy; we routinely entrust providers with our confidential documents, assuming they will keep them safe.
End‑to‑end encryption (E2EE) has emerged as the gold standard for protecting these exchanges, but there are misconceptions around what E2EE means, and an increasing prevalence of tools that claim E2EE but which do not deliver on that promise.
What is end-to-end encryption (E2EE)?
End‑to‑end encryption means that only the sender and intended recipient can ever see the unencrypted data.
No one else can access the cryptographic keys needed to read the data - including the service provider. This is known as a zero-knowledge architecture.
Encryption and decryption happen solely on the users’ devices, and not on an intermediary server.
There are many sources1 that confirm this definition of E2EE.
Why does using E2EE matter?
Services that do not implement true E2EE may still encrypt your data in transit and at rest, but if the provider has access to the decryption keys, they can still technically access your data. This creates two main risks for the user:
-
Privacy - Without E2EE the provider could potentially read, modify or share your data, or even use it to train AI models without your consent.
-
Data breaches - Without E2EE the provider not only becomes a more attractive target for an attacker, but if the attacker is successful, your data may be compromised too.
It is important to realise that, without E2EE, it’s not just a matter of trusting your provider doesn’t look at your data; you also have to trust that they won’t get hacked.
What is required of a true E2EE service?
The following describes what is required for a service to be considered truly end-to-end encrypted:
-
Client-side key generation – The encryption key is created on the sender’s device. It is never revealed to the server.
-
Data is protected before leaving the sender’s device – Files or messages are encrypted before leaving the sender’s device and then transmitted to the service provider’s infrastructure in this encrypted form.
-
Key sharing without server access – The decryption key must reach the recipient without the service provider ever having access to the key. This can be achieved in various ways2.
-
No server-side decryption – The provider’s servers only ever handle encrypted data and never perform decryption. This ensures they cannot technically access, analyse or alter your content.
If any of these properties are broken, such as the key being sent to the server, or the data being decrypted to enable the provider to virus scan the data, the service is not end-to-end encrypted - even if marketing materials say otherwise.
How to spot a pseudo-E2EE service
Most encryption products don’t claim end-to-end encryption, and instead centre their marketing around the principles of encryption in transit and encryption at rest 3. These are important security measures, but they do not provide data privacy or protect against data breaches in the same way that E2EE does.
However, services that do claim to offer end-to-end encryption may not always deliver on that promise. Here are some anonymised patterns that we’ve observed while reviewing secure email and file-sharing platforms:
-
Keys in the server requests – One solution we reviewed presents recipients with a “secure link” containing a parameter named “endtoendencryptionkey”. Unlike URL fragments, this parameter is part of the query string sent to the server, meaning the provider receives the decryption key along with the request.
-
Server-side decryption – One solution claiming E2EE is clearly decrypting email bodies on their servers and sending them unencrypted to the recipient. This is easy to spot using browser developer tools, but for a non-technical user it may not be obvious.
-
Malware scanning on upload - Some file‑transfer systems promise end‑to‑end encryption AND malware scanning of files. Whilst this technically could be achieved if both are performed on the user’s device before uploading, some providers we reviewed are clearly performing malware scanning on their servers, meaning they must be decrypting the files first.
-
Key management by the provider – A number of services claim E2EE but manage encryption keys on behalf of users. In one case, a provider states that “all encryption keys are stored securely in our key management system”. If the provider manages the keys, they can technically access your data, even if they promise not to look at it.
-
Extra key management service requirements – Some platforms advertise E2EE but on closer examination this is only achieved through the use of an additional key management service. This might be a hosted service - meaning a third party provider still has access to your keys - or self-hosted, which adds complexity and friction to the user experience. Google Workspace Client‑Side Encryption (CSE) is one example of this pattern.
Hexiosec Transfer: true E2EE by design
Hexiosec Transfer was architected from the ground up as a zero‑knowledge platform. Here’s how we ensure genuine end‑to‑end security:
-
Encryption happens in your browser - When you upload a file via Hexiosec Transfer, an encryption key is generated locally and your data is encrypted in your browser (on your device) before anything is sent across the network. Once encrypted, the file is sent to our servers without the key.
-
The decryption key is never accessible to Hexiosec - After upload, the Hexiosec Transfer application generates a download link that includes both the encrypted file’s location and the decryption key. Only people with the full link can decrypt the file, and since the key is in the URL fragment it is never shared with Hexiosec. In some cases, we instead facilitate key agreement between the sender and receiver. In either case, we never see your keys so our servers can only ever see your ciphertext, and never your file contents.
-
Additional privacy controls - To complement E2EE, you can set controls such as download limits, expiry times, optional passwords and email address verification. You can also revoke access at any time to prevent further downloads. These features enhance security without sacrificing privacy because enforcement happens via metadata, and never by decrypting your content. Hexiosec Transfer also supports secure file‑request links, allowing others to share files with you with the same end‑to‑end protections, even if they don’t have an account.
-
Cryptographic transparency - For those who want to peek under the hood, Hexiosec Transfer uses AES‑256‑GCM for encryption, with keys derived using PBKDF2 and HKDF. When requesting files, keys are negotiated using ECDH with a NIST P‑384 curve. Your browsing traffic is also secured with TLS 1.2 or above, but TLS is a secondary layer; the critical encryption happens client‑side.
Conclusion: privacy should be provable, not just promised
When evaluating secure‑communication tools, look beyond the marketing terms and ask where the keys live, who can see the plaintext, and whether the provider could access your data if they chose to.
We built Hexiosec Transfer to meet the strictest definition of E2EE. Files are encrypted in the browser, keys never reach our infrastructure and only the intended recipients can decrypt the data. While we can’t control how others define “end‑to‑end,” we believe that privacy should be provable, not just promised.
If you have any questions about end-to-end encryption or want to learn more about Hexiosec Transfer, feel free to reach out to us or book a demo.
-
Sources of E2EE definition:
Cloudflare : “End-to-end encryption (E2EE) is a type of messaging that keeps messages private from everyone, including the messaging service.”
Wikipedia : “No one else, including the system provider, telecom providers, Internet providers or malicious actors, can access the cryptographic keys needed to read or send messages.”
IBM : “E2EE differs from other encryption methods because it provides data security from start to finish. It encrypts data on the sender’s device, keeps it encrypted during transmission and decrypts it only when it reaches the recipient’s endpoint. This process ensures that service providers facilitating the communications, such as WhatsApp, cannot access the messages. Only the sender and the intended recipient can read them.” ↩︎
-
Here are two ways keys can be shared without the server having access:
a. Embedding the decryption key in the URL fragment (the part after the
#). Browsers automatically strip the fragment from HTTP requests so the key is never sent to the server.b. Through shared secret schemes that allow two devices to establish a secret key together, without the service provider ever knowing what the key is. While the provider facilitates the exchange through its infrastructure, it remains completely blind to the contents of the secret. ↩︎
-
Encryption in transit, such as standard TLS used by most websites, protects data as it travels between your device and the provider’s servers, preventing interception by third parties during transmission. Encryption at rest protects stored data from certain types of storage-level compromise, but if the provider has access to the decryption keys, a compromised server or insider threat could still expose your data. Both measures are important, but they do not prevent the service provider from accessing your unencrypted data, or your data being exposed in a breach. ↩︎
Related Posts
