Security
Lasbolt protects your secrets from a stolen disk, a network attacker and, for end-to-end folders, a hacked server. It does not protect server-readable data from the operator. This page is a short version of the threat model. The threat model has the full text, and Cryptography has the algorithms.
What the server sees
The client makes all keys on your device. The server gets a derived auth key and ciphertext. It never gets the master password or the encryption key.
flowchart LR
subgraph D["Your device"]
P["Master password"] -->|"Argon2id"| M["Master key"]
M -->|"HKDF"| K["Encryption key"]
M -->|"HKDF"| A["Auth key"]
K --> F["Folder and item keys"]
end
subgraph S["Server"]
H[("Auth key hash")]
C[("Ciphertext")]
end
A --> H
F -->|"encrypt"| C
Two kinds of folder
| Server-readable | End-to-end | |
|---|---|---|
| Server can search and serve agents | Yes | No |
| Stolen database or backup | Safe | Safe |
| Hacked server, passive | Data is lost, by design | Safe |
| Hacked server, active | Data is lost | Safe with the CLI and native apps. Not safe in the web app. |
| Recovery without the master password | Operator reset | Recovery kit only |
You choose for each folder. E2E is permanent for a folder.
Who can read what
| Asset | Where it lives | Who can read it |
|---|---|---|
| Master password | Your head, and the client during login | You only |
| Encryption key | Client memory | Your clients only |
| E2E values, names and metadata | Server database, encrypted with item keys | Members of the folder, and keys with a grant |
| Server-readable values | Server database, encrypted with the data key | The running server, you, agents in scope |
| Backups | Backup folder, off-site copies | The operator (the server key or the backup identity is needed) |
| Recovery code | Paper or a file, offline | The holder |
| Tree shape, sizes, times, names of E2E root folders | Server database | The running server |
The server can also see metadata of the vault, such as how many items you have and when you change them.
Adversaries
| Adversary | Promise | Limit |
|---|---|---|
| Network attacker | Cannot read or change traffic | The operator must set up TLS |
| Stolen server disk or backup | All data stays encrypted | With the passphrase provider, offline guessing runs at Argon2id cost. Use a long random passphrase. |
| Server compromised, passive | E2E data and the master password stay secret | Server-readable data is lost, by design |
| Server compromised, active | The CLI and native clients detect forged E2E operations | The web client has no promise for E2E: the server sends its code |
| Online attacker at the login | Rate limits, TOTP, and slow key derivation on the client | Behind a proxy, the operator must set --trusted-proxy |
| Stolen device or session | Remove it in Settings > Devices. A device token has no E2E keys. | A device that read a secret can keep a copy |
| Tricked AI agent | Scoped keys, expiry and per-use approval limit the damage | The MCP server has no tool that returns a secret value. Masking and “inject only” are a help, not a boundary. |
Why the web client is weaker
The server sends the JavaScript and the WASM of the web app. A server that is under the control of an attacker can send code that reads E2E data after you unlock. This is true for every web-based E2E product. For the strongest promise, use the CLI or a native app and sign in with lasbolt login --password.
What E2E does not hide
The server sees the shape of your vault and when you use it. It can deny service. It can withhold changes from a new device. Clients write signed checkpoints, so a server that hides or changes older operations is found, and the client then refuses writes to that folder. A server that shows two devices two different histories is not found by a checkpoint alone.