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.

What the system keychain covers

Proxy passwords, the sign-in password a profile carries and the passphrase for the sync folder are sealed by the operating system, in the same place it keeps your other secrets.

The app holds no key of its own, because a key that ships inside a program is available to everyone who downloads that program. Where the system can seal, the seal is the system's.

When there is nothing to seal with

On a machine where the system offers no sealing, 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.

A sealed value that will not open is kept in its sealed form rather than dropped. One bad day at the keychain then costs you a reading, not the value itself.

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. The app never claims a seal it did not apply, and that silence is the whole of the signal today.
A passphrase you lose cannot be recovered. Archives in your folder stay closed, and there is no second key anywhere for them.
Exporting settings to a file is a second road, and that file is not encrypted. Choosing to include credentials 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
The sign-in and proxy passwords are sealed, and a value that will not open is not erased: apps/desktop/src/lib/proxies.js · apps/desktop/test/login-in-keychain.js · apps/desktop/test/proxy-password-sealed.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?: The operating system, for the values it seals. For an archive it is you, through a passphrase that the sync folder never sees.
What is different on Windows?: The seal is the system's own there too. Owner only permissions are not, 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.

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 Download ARMANOS