How the encryption actually works

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.

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, and it is more than sizes and timestamps: which people are in which tome and in what role, who exchanges messages with whom and whether those messages were delivered and read, the exact byte size and file type of every upload, the duration and dimensions of every video, your username and profile fields, and every timestamp.

That residue is real and we are not going to describe it away. Metadata is informative, and a file of a known size and type can be confirmed present in a tome without decrypting anything. 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. Our security audit sets out the full list.

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 sign in with, no password database to breach, and no email address to phish an account recovery through.

What we have added since is a way back in that does not reintroduce any of that. Recovery is optional and off by default. If you turn it on, your browser seals a copy of your key under a passphrase we generate and never receive, and we store only the sealed result. It cannot be phished out of us, because we have nothing to give up: no password validates a login, and the sealed copy opens only in your browser.

You are still trading something. With recovery off, we hold nothing of yours that could ever be opened. With it on, we hold something we cannot open - a smaller claim, honestly a weaker one, and the reason it is a choice rather than a default. Our security audit sets out exactly what it costs.

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 with nothing set up. Recovery is optional and the export backup is manual, so if you skip both, a cleared browser ends the account and nobody can undo it. Do one of the two on your first day.

Forgetting a passphrase you chose. If you enable recovery and lose its passphrase, or seal an exported backup and lose that one, the sealed copy is as unopenable to you as it is to us. We cannot reset either. That is the same property that makes them safe to store, and it is why we offer to generate the passphrase rather than let you invent one.