Encryption at rest

A backup, a home folder your cloud already syncs and a disk handed to a repair shop all carry the same file out of your hands. What that file is worth afterwards comes down to where the key was.

Encryption at rest is protection applied to stored data, so a copy of the file is worth nothing to whoever holds no key.

Three questions decide it

The phrase says almost nothing on its own. These three answers are what separate a real protection from a label.

Where does the key live
Inside the program, inside the operating system, or only in your head. Only the last two survive the file being copied.
What exactly is covered
One field, one file, or the whole folder. A sealed library means little if the same value also lies in plain sight next door.
What happens with no key
Writing the value plainly is honest. Writing it plainly under a mark that says sealed is worse than writing it plainly.

Sealing on each system

Proxy passwords, the sign-in password a profile carries and the passphrase for the sync files are sealed by the system on Windows, with a key tied to your Windows account. On macOS they are sealed with a key that ships inside the program, and on Linux they are written as typed.

A key that ships inside a program is available to everyone who downloads that program, and the macOS seal rests on exactly such a key. So on macOS and Linux whoever holds a copy of the file can read these values.

When a seal is not protection

On Linux the value is written as it is, and no mark claims otherwise. A mark of protection over an unprotected value is the one outcome worth avoiding, because it stops you from taking your own precautions. On macOS the seal is exactly that case, because its key ships inside the program.

A sealed password that will not open is kept in its sealed form rather than dropped: the sign-in password, the sync passphrase, and the proxy password in the library, in a template and in a profile. One failed opening then costs you a reading, not the value itself. Next to the proxy the program says the password has to be typed again.

An archive carries its own lock

A profile that moves with its session travels as one encrypted archive, whether you carry it by hand or through a folder your cloud already syncs. The cipher is AES-256-GCM and the key is stretched from your passphrase with scrypt.

The archive is sealed against tampering as well as reading, so a wrong password comes back as an honest refusal rather than as rubbish that looks like a session. The passphrase itself never enters the folder.

Permissions are not encryption

Files holding secrets are written for their owner alone, and those permissions travel with a copy on macOS and Linux. On Windows they mean nothing, and what closes the folder there is the user account it sits inside.

Permissions answer the question of who may open a file. Encryption answers what the file is worth once somebody has opened it, and the second question is the one a backup raises.

Often confused with

Encryption in transit
That protects a message between two machines and ends the moment the message is written down.
Full disk encryption
It protects a machine that is switched off, and gives nothing once you have logged in and the disk is open.
Hashing
A hash is one way on purpose, which is right for a password nobody needs to read back and useless for one you do.

What this does not do

It does nothing while the machine is open. A value in use sits in memory in the clear, and so does the browser while a profile runs.
It does not cover the whole profile directory. What the browser writes there is the browser's own, kept by its own rules rather than by ours.
Nothing on screen says whether a value was sealed or with what. In the file, a value sealed on macOS looks the same as one sealed on Windows, while its key ships inside the program.
A passphrase you lose cannot be recovered. Archives in your folder stay closed, and there is no second key anywhere for them.
Exporting profiles to a file with the Export button is a second road, and that file is not encrypted. Pressing Include secrets puts the sign-in pair, the one time key and proxy passwords into it in readable form.

Check it

Every claim above has a file behind it, and most have a stand that fails when the claim stops being true.

Files holding secrets are written for their owner alone and whole: apps/desktop/src/lib/secureFile.js · apps/desktop/test/secrets-on-disk.js
What each system does to the sign-in and proxy passwords, and a password that will not open is not erased: apps/desktop/src/lib/proxies.js · apps/desktop/src/lib/sealedPassword.js · apps/desktop/test/login-in-keychain.js · apps/desktop/test/proxy-password-sealed.js · apps/desktop/test/шифрование-правда-по-системам.js · apps/desktop/test/пароль-без-ключа-не-теряется.js
A session archive is encrypted, and a wrong password gets an honest refusal: apps/desktop/src/lib/bundle.js · apps/desktop/test/profile-bundle.js · apps/desktop/test/session-sync-folder.js
The proxy password in the database is sealed with a key kept outside it: apps/server/src/common/crypto/secret-box.ts · apps/server/test/proxy-secret.js

Questions

Is this the same as full disk encryption?: No. Full disk encryption protects a machine that is powered off, while this protects a single file after it has left one.
Who holds the key?: On Windows the system holds it, tied to your Windows account. On macOS the key ships inside the program, so everyone who has the program has it, and on Linux there is no key, because the values are written as typed. For an archive it is you, through a passphrase that the sync folder never sees.
What is different on Windows?: Only there is the seal the system's own, tied to your Windows account. Owner only permissions do not work there, so the folder is closed by the user account it sits in.
Is a proxy password on your server in the clear?: It is sealed in the database with a key kept outside the database. Somebody holding both can read it, which is exactly why we do not call the product zero knowledge.
Why not put a key inside the app?: Because everyone who downloads the app would have that key, and the value would be as open as before while looking closed. On macOS this is what happens: the seal there rests on a key that ships inside the program.

Next to this

See what is written where

The security page lists every file, every value that leaves your machine and every edge where a protection stops.

Read the security page Sign-ups paused for now