Security
How the encryption actually works
Four keys, in a hierarchy, none of which we hold. This page describes the design in enough detail to argue with, and finishes with the parts of it that will not protect you.
The key hierarchy
RSA-4096 keypair, per person
Generated by the Web Crypto API in your browser when you register. The public half is uploaded so other people can share with you. The private half is stored on your device and is never transmitted, in any form, at any point.
AES-256-GCM key, per tome
Generated in the browser when you create a tome. It encrypts everything inside that tome. It reaches our servers only after being wrapped with a member's RSA-4096 public key, which is useless without their private key.
Content, per item
Every image, video, thumbnail, post body, comment and message is encrypted with the tome key under its own initialisation vector. Filenames, titles, descriptions and the tome's own name and description are encrypted too.
What the server ends up with
Ciphertext, initialisation vectors, public keys, and tome keys wrapped for individual members. No private keys, no tome keys in the clear, and no plaintext of anything.
Why sharing does not break the encryption
The hard problem in end-to-end encryption is not encrypting something for yourself. It is encrypting something for a group whose membership changes. Most services solve it by quietly dropping out of end-to-end encryption the moment you share, which is why iCloud Shared Albums sit outside Apple's Advanced Data Protection.
A tome has one AES-256-GCM key. Every member holds a copy of that key, and every copy is stored on our servers wrapped with that member's RSA-4096 public key. When you invite somebody, your browser decrypts the tome key with your private key, re-wraps it with their public key, and uploads the wrapped result. At no point does an unwrapped tome key exist on our side.
The consequence is that a shared tome is exactly as encrypted as a private one. There is no weaker mode you slip into by adding a second person.
Why the metadata is encrypted too
Encrypting the file and leaving the filename readable gives away most of what an observer wanted. "Scan of divorce settlement.pdf" does not need decrypting to be informative, and a folder tree is often more revealing than its contents.
So the tome's name and description are encrypted, filenames are encrypted, post titles and bodies are encrypted, comments are encrypted, and video thumbnails are generated on your device and encrypted before upload. What remains readable to us is structural: that an account exists, that it has tomes, that those tomes contain a certain number of items of certain sizes, and when they were uploaded.
That residue is real and we are not going to describe it away. Sizes and timestamps are metadata, and metadata is informative. It is a much smaller disclosure than the file itself, and it is the smallest one we know how to make while still running a service that works.
Why there is no password
Most encrypted services derive your key from your password. Proton does, Ente does, MEGA does. It is a reasonable design and it buys you recoverability, because a password can be re-entered on a new device and a recovery phrase can restore it.
It also means the strength of your encryption is the strength of your password, and passwords are phished, reused and leaked at scale. We took the other route: the keypair is the account. There is no password to be weak, no password database to breach, and no email address to phish an account recovery through, because there is no account recovery.
You are trading a safety net for the removal of an entire attack surface. That is a real trade with a real cost, and the cost lands entirely on you if you lose your key.
What this design does not protect you against
A compromised device. If somebody has your unlocked laptop, they have your private key and everything it opens. No server-side design can help with that.
A member you invited. Anyone holding the tome key can decrypt the tome and can copy what they find. Encryption controls who can read, not what a reader then does. Invite accordingly.
Code delivered by us. Your browser fetches the encrypting code from our servers, so a compromised or legally coerced server could serve modified code to a specific user. This is the structural weakness of all browser-based encryption, ourselves included, and the 2022 ETH Zurich work on MEGA is the best illustration of why it is worth taking seriously. It is also why we keep recommending you watch your own network tab rather than take our word for it.
Misuse of the service by other people. We cannot scan for illegal material, because we cannot read anything at all, and we are not going to present that as a virtue. We act on what is reported to us, remove content and close accounts. Being unable to read a tome is a property of the design, not a position we treat as an excuse.
Losing your key. There is no recovery. Export a backup on your first day and keep it in a password manager.
Check it in about ninety seconds
- 01 Open your browser's developer tools and select the network tab.
- 02 Upload a photo to a tome.
- 03 Find the upload request and open its payload.
- 04 Look for a JPEG or PNG header. There should not be one. What is there should be indistinguishable from noise.
- 05 Do the same thing on any other service that claims end-to-end encryption, and on one that does not, so you know what both look like.
This is the only assurance that does not require trusting a company, and it works on every service in our comparisons.
Questions about the design
AES-256-GCM for content, RSA-4096 for key exchange between members, both through the browser's Web Crypto API rather than a hand-rolled implementation. Each encrypted item carries its own initialisation vector.
In your browser, on the device where you created the account. It is never sent to us. That is also why moving to a new device requires exporting your key and importing it there.
Whoever took it has encrypted blobs, initialisation vectors, public keys and wrapped tome keys. None of it decrypts without private keys that exist only on users' devices. It would be a very large collection of noise.
We can be compelled to hand over what we hold, and we would comply with a lawful order. What we hold is ciphertext. There is no key on our side to hand over alongside it, because there never was one.
Not yet, on either count. Ente publishes its client and server code and has been audited; Proton publishes audited clients. If verifiable openness is your first requirement, they are ahead of us today and we would rather point you at them than pretend otherwise.
On report rather than by detection. No proactive scanning is possible here, so we rely on what is reported to us and respond by removing content and closing accounts. The structure limits the damage: tomes are invite-only, there are no public links, nothing is indexed and nothing is discoverable, so there is no audience for anyone who needs one.
That your browser fetches the encrypting code from our servers. A compromised or coerced server could serve different code to a targeted user. This is true of every browser-based encrypted service, and it is the reason the network tab check is worth performing rather than assumed.
The design is only worth anything if you use it.
A username, a tome, and an export of your key backup before you put anything in it.
Create an account