What is end-to-end encryption, and why does it matter?
Many services say they encrypt. But who holds the key? A plain explanation of end-to-end encryption, and why it matters for passports and payslips.
Encryption in plain words
Encrypting means turning a file into unreadable characters. Only someone with the right key can make it readable again. Without the key, an encrypted passport copy is nothing more than a string of random bytes.
So the key question is not whether a service encrypts, but who holds the key.
Three kinds of encryption
When a service says it encrypts, it can mean three different things.
| Kind | What it protects | Who can read along |
|---|---|---|
| In transit (the padlock in your browser) | The file while it travels over the internet | The service itself, once it arrives |
| On the server | The file on the service's disk | The service, because it also keeps the key |
| End-to-end | The file from sender to recipient | Only sender and recipient |
The first two are useful and common today. But the service can still open the file. With end-to-end encryption, encryption already happens on the sender's device and decryption only on the recipient's device. The key never reaches the service.
Why it matters
A passport copy, payslip or medical document is exactly the kind of file used for identity fraud. End-to-end encryption helps in situations you do not control yourself:
- A data breach at the service. Whoever breaks into the servers only finds unreadable files.
- Staff or administrators of the service. They cannot view the contents either.
- A request or demand from a third party to the service. It cannot hand over readable files it cannot open itself.
- Files that stay on the server for a while. They remain unreadable to the service too.
The GDPR asks organisations to secure personal data appropriately, and explicitly names encryption as an example (Article 32). What is appropriate depends on the data and the risk. For identity documents and financial records, that risk is high.
What end-to-end encryption does not protect against
Encryption is not a cure-all. It helps to know its limits:
- The wrong recipient. If you send the link to the wrong person, or it is forwarded, that person can open the file. Encryption does not check who is on the other side.
- An infected device. If the sender's or recipient's computer is compromised, an attacker can watch at the moment the file is readable.
- What happens after download. The file then sits readable on the recipient's device, and what happens to it there is up to them.
- Trust in the software. When encryption happens in the browser, you rely on the service delivering the right code.
The first limit matters most for sensitive documents. That is why TransferGuard combines encryption with a check of the recipient.
How it works at TransferGuard
- Your browser creates a random key and encrypts the file, including its name, before it is uploaded.
- Do you choose to share the link yourself? Then the key is in the link, after the # sign. Browsers never send that part to a server. Do you let TransferGuard email the link? Then we keep the key encrypted and only release it after the recipient has confirmed with the email code or, if you choose, an identity check. Only when you share the link yourself is it end-to-end encrypted.
- The recipient first confirms with an email code. With Certified Delivery you can also ask for an SMS code or an identity check: a photo of the identity document and a photo of their face.
- Only then does the recipient receive the encrypted files, and their own browser decrypts them.
What TransferGuard does see: the recipient's email address, times, the size of the files and a digital fingerprint (SHA-256) of each file, plus the details of an SMS code or identity check if you use one. The contents and the file names are encrypted. By default we keep the key encrypted and only release it once the recipient has confirmed. Only when you share the link yourself can we not reach it at all.
Four questions to test a service
- Is the file encrypted on my device, before it is sent?
- Can the service itself open my files or file names?
- Where is the key kept, and does it ever reach a server of the service?
- Does the service check who opens the file, or only who has the link?
If you get a vague answer to the second and third question, it is probably not end-to-end encryption.