What encrypted at rest protects, and what it does not

Almost every security page on the internet says your data is encrypted at rest. It is true, it is worth having, and it answers a narrower question than most people think. The question it answers is: what happens if somebody gets a copy of the data? The question it does not answer is: who else holds the key?

This post is about where Nemi draws that line, in specifics. What we encrypt, how, why some things stay readable on purpose, and the one place in Nemi where we cannot read your work at all.

What does encrypted at rest actually mean?

Data is at rest when it is sitting somewhere: on a disk, in a database, in a backup. Encrypting it at rest means what is written there is ciphertext, and turning it back into your words needs a key. The protection is only as good as the distance between the ciphertext and that key. If both sit in the same place, stealing one steals the other.

So the honest version of the phrase always comes with a second sentence: and the key is held by somebody. For most services, including this one outside a Vault, that somebody is the service itself, because the service has to read your data to do anything useful with it.

What does Nemi encrypt, and who holds the key?

The files you upload live with our storage provider in Amsterdam, which encrypts every object with AES-256. The provider manages those keys. That protects the physical disks in their data centres. It does not make a file unreadable to somebody holding valid credentials for our storage, because the provider decrypts for whoever is allowed to ask.

What you write gets a second layer of our own. The content of documents, sheets, canvases and forms, the answers people send to your forms, comments, chat in rooms and meetings, conversations with Nemi AI, notes in Calendar and messages on links are all encrypted by our server before they are written to the database. Forty columns across the database go through it, and the key lives in the server's environment, never in the database itself. A copy of the database, or of one of its backups, is a copy of ciphertext.

Why does the same sentence never encrypt the same way twice?

Try it. The figure below runs the same construction our server uses, in your browser, under a key this page made a moment ago. Change the sentence, then save the same words again and watch the stored value change completely.

The highlighted characters at the start are the IV, the initialisation vector: twelve random bytes drawn fresh for every single write. AES-GCM mixes them into the encryption, so the same words under the same key never produce the same ciphertext. That matters more than it sounds. Without it, two people who wrote the same sentence would leave identical ciphertext behind, and anyone holding a copy could tell, or could guess a short value and check the guess against the stored one.

The last button shows the second guard. Every column gets its own key, derived from the master key with the column's name mixed in, and that name is also bound into the ciphertext as authenticated data. Move a value from the comments into a document and it does not open as a document: it fails, loudly. GCM's authentication tag also means a value that has been altered by even one bit fails rather than decrypting to something slightly wrong.

Why can Nemi not search an encrypted column?

The random IV has a price, and we pay it on purpose. A database finds rows by comparing stored values: this title equals that one, this name starts with those letters. When the same word encrypts differently every time, there is nothing to compare. An encrypted column cannot be searched, sorted or matched by the database at all; anything that needs to look inside one has to decrypt it in the server first.

That is why the names of files, folders and documents, and the titles and places of calendar events, are not encrypted this way. You search and sort by them dozens of times a day, and doing that over ciphertext would mean decrypting a whole workspace to answer one query. They are protected by access controls and by the security of our servers, and the privacy policy says so in those words. If a name itself is the secret, that is a job for a Vault.

Why are tokens hashed instead of encrypted?

Some of what we store is not content but a credential: the token behind an invitation, an upload link, or a device that stays signed in. For those, encryption is the wrong tool, because encryption is reversible by design. Wherever a token never has to be shown to you again, we keep only its SHA-256 hash. When it is presented, the server hashes what arrived and looks that up. A leaked copy of the table is a list of hashes, and a hash opens nothing.

A fast hash with no salt would be the wrong choice for a password, which a person picks and an attacker can guess. These tokens are random values of 128 bits or more generated by our server, so there is no list of likely candidates to try. Passwords you put on links are stored as one-way hashes too. The same idea, a hash that can be compared but not reversed, is how share link statistics count visitors without storing their address.

So who can read my data?

This is the part most security pages skip. Pick a person below and see what each of them could actually read.

The middle case is the one to be clear about. Our servers hold the key, because they need to read your content to save it while you collaborate, to search it, to convert and preview it, to serve the links you publish and to let Nemi AI work with it. So encryption at rest protects your content against a leaked or stolen copy of our data. It does not protect it from us, and we could still be compelled to produce it. Inside a workspace, which of your colleagues may change what is a separate question, answered by a role check on every write.

Encryption at rest answers what happens to a stolen copy. It does not answer who holds the key.

Is end to end encryption the same as encryption at rest?

No, and the difference is exactly who holds the key. Your files and what you write are encrypted at rest, with the key on our servers, and names and titles are not encrypted at all. A Vault folder is end to end encrypted, and it is the only part of Nemi that is. The key is generated in your browser and unlocked there by your passkey or passphrase. Files and their real names are encrypted on your device before anything is uploaded, so what reaches us is ciphertext we cannot open with database access, storage access or both. Adding somebody happens on an existing member's device, which re-encrypts the key to them; we pass the result along and cannot add ourselves.

That guarantee has a cost, and it is the same guarantee seen from the other side:

• We cannot generate previews or thumbnails, convert, compress or scan a Vault file for malware, because each of those means reading it.
• We can still see that the folder exists, how many files it holds, their sizes and dates, and who its members are.
• If you lose your passkey or passphrase and your recovery code, the files are gone. Not lost to you and recoverable by us: gone.

That is why Vault is a folder you choose for the contract, the passport scan and the thing that must never leak, and not the default for everything. The Vault page shows what it is for, the help centre explains how to set one up, and the security page lists everything else we do to protect what is outside one.