How the end-to-end encryption works

Sternway encrypts your data on your device before anything is sent, with keys the sync server never has. The server stores ciphertext and the little metadata it needs to sync it. This page explains the pieces and how they fit together.

From your password to your keys

When you create an account, your password goes through Argon2id, a password hash built to be slow and memory-hungry, so each guess costs an attacker real work. An account made on the desktop uses 3 passes over 256 MiB; one made on a phone uses 2 passes over 64 MiB, which a phone can afford. The result is a 32-byte master key.

The master key is split, with HKDF-SHA256, into two keys that have nothing to do with each other:

• the auth key, which is sent to the server to sign in. The server stores only a hash of it.
• the key-encryption key, which never leaves the device. It wraps (encrypts) your account’s own key pairs and your personal vault’s key.

So the server can check that it is you without ever being able to unwrap your keys, and your password itself is never sent anywhere.

Sternway also refuses a server that asks it to derive the master key with less work than it should: below 2 passes over 64 MiB, or below what this device already knows for the account. A server cannot make your password cheaper to guess by lowering the cost.

Your account’s key pairs

Every account has two long-term key pairs, made on the device when the account is created: X25519 for receiving sealed keys, and Ed25519 for signing. Together they are the account’s identity. Their fingerprint, written as six groups of five digits, is the safety number your teammates compare with you.

Vaults and items

Your data is kept in vaults: your personal vault, and the team vaults you have access to. Each vault has its own random 256-bit key.

Every item (a host, a key, a snippet, a known host, a setting) is sealed on its own with XChaCha20-Poly1305 under its vault’s key, with a fresh random 24-byte nonce. The item’s id, type, vault and the vault key’s version are bound in as associated data, so the server cannot move an item to another vault, pass it off as another kind of item, or replay it under another key without the seal failing. Inside the sealed data each item also carries a version counter and the id of the account that wrote it, so a device can tell when the server serves an older version again.

What the server sees of an item: its id, its vault, its type, its revision, its key version, whether it was deleted, and its size. Not its contents.

Session logs (when you turn on syncing them) are sealed the same way, in chunks. Vault names are encrypted too.

How a team member gets a vault’s key

A team vault’s key has to reach each member without the server seeing it. The team owner’s app (or an admin’s, on a team with roles) seals the vault key to each member’s X25519 key, with a sealed box, and signs it. A member’s app opens it with their own private key, and only accepts it from a sender and at a key version that the team’s signed member list allows. That list is signed by the owner, and every member’s app checks it, so the server cannot slip in a key of its own or a member of its own. See How teams and trust work.

When a member is removed, the vault gets a new key, sealed only to the people who still have access. Items written from then on use it.

The recovery kit

Your recovery kit holds a random 256-bit recovery key, printed as 52 characters. The server keeps your key-encryption key wrapped with it, and a hash of a separate key derived from it to check a recovery request; the recovery key itself never reaches the server. With the kit you can set a new password and unwrap your keys again, and the kit stays valid afterwards. Changing your password the normal way makes the old kit stop working: make a new one then. Without the password and without the kit, nobody, the server’s operator included, can recover your data.

On the device

Without any account, the data on the device is still encrypted at rest. Each profile has a device data key that seals every row of the app’s database and every snapshot, with the same XChaCha20-Poly1305. That key is held by the operating system’s keychain: Electron’s safeStorage on the desktop (the Windows data protection API, the macOS keychain or the Linux Secret Service), the Android Keystore through Expo’s SecureStore on the phone. On a Linux desktop with no keychain, a passphrase you choose protects it instead, through Argon2id.

The app lock (PIN or passphrase) is a screen in front of the open app, not another layer of encryption: while the app is locked, the keys it already unlocked stay in memory.

Backup files

An exported .sternwaybackup file is encrypted with a key derived from the backup password you set, with Argon2id, independent of any account, server or device key. That is why it opens on any device that knows the password.

What this does not protect

Encryption protects what is stored and what travels. It does not protect against malware running on your own device as your user, which can read the keychain and the app’s memory as you can, and it does not hide the metadata listed above from the server. Threat model goes through each case.