Security Model

This document describes Claspt’s encryption architecture for technical users and security auditors.

Overview

Claspt encrypts on your device. Your master password and encryption keys never leave your device, and secret-block values (passwords, keys, and anything inside a :::secret block) are encrypted client-side before they are ever written to disk or synced — the Claspt sync server only ever receives opaque ciphertext for them.

Note the one deliberate exception: non-secret note text is stored in plaintext in your .md files so the notes stay portable and searchable. If you keep the vault folder in a file-sync service of your own (iCloud Drive, Google Drive, Dropbox), that non-secret text syncs to that provider as plaintext, exactly as it sits on your disk. Secret-block values remain encrypted everywhere. So the zero-knowledge guarantee is absolute for your keys, master password, and secret values — and, for note content, depends on which sync backend you choose. With Claspt Sync the whole vault travels as ciphertext.

Encryption Primitives

Component	Implementation
Cipher	AES-256-GCM (via ring crate)
Key Derivation	Argon2id (64 MB memory, 3 iterations, 4 parallelism)
Nonces	96-bit, unique per block per save
Key Storage	Encrypted in vault.key, never synced
Memory	Key material wrapped in zeroize and wiped on lock; decrypted values are not scrubbed (see Memory Safety)

Key Derivation

When you create a vault, Claspt:

1. Generates a random 256-bit master key.
2. Derives a password key from your master password using Argon2id (64 MB, 3 passes, 4 lanes).
3. Encrypts the master key with the password key using AES-256-GCM.
4. Stores the encrypted master key in .securenotes/vault.key.

When you unlock the vault, Claspt re-derives the password key from your password and decrypts the master key. The master key is held in memory (zeroed on lock).

Secret Block Encryption

Each :::secret block is encrypted individually:

1. A fresh 96-bit nonce is generated for each block, on each save.
2. The plaintext value is encrypted with AES-256-GCM using the master key.
3. The ciphertext is Base64-encoded and stored as enc:v1:<base64>.
4. The label remains plaintext for searchability.

What Is Encrypted

• Every secret block’s value.
• A page marked encrypted, in full.
• Any attachment you chose to encrypt.
• The journals that describe your secrets (password health, fill history, share log, templates, extension preferences).

What Is Not Encrypted

The following remain plaintext for markdown portability:

• Page content (outside :::secret blocks)
• Secret block labels
• Page titles, folder names, tags
• YAML frontmatter (id, timestamps, metadata)

Plaintext at rest

A save reaches the file on disk, the vault’s version history, sync, every other synced device and any backup that copies the folder. Since 4.2 a credential never rests in plain text in any of them:

• A page that holds a recognisable credential outside a secret block is stored fully encrypted until the credential is inside a block or gone. The rule recognises token shapes (cloud keys, API keys, private keys) and password-like fields with generated-looking values. It is conservative, so ordinary notes are never sealed by it, and a page you chose to encrypt is never unsealed by it. The editor shows a band under the title that says why the page is sealed and offers to convert the flagged lines.
• A paste that looks like credentials offers the conversion the moment it lands, before the first save.
• Version history can be started afresh from Settings › Utilities › Version History. Every earlier version is removed on that device and history starts again from the pages as they are; the pages are never touched. Use it once for any page whose earlier versions held a credential before it was made a secret. Each synced device keeps its own history, so run it on each.
• A value that just became a secret leaves the recent versions of its page. After a conversion, the recent versions holding the value are rewritten so it appears in none of them. If the value sits further back than the app will rewrite on its own, the inspector says so and points to the reset.

What remains: a credential the rule does not recognise stays plain until you convert it, and a backup taken in that window keeps it.

Sync Security

With Claspt Sync (Pro):

• vault.key is never synced; the server holds the vault key only wrapped under a key derived from the master password, which it never sees.
• Every device signs its sync requests with its own key; the server keeps only the public half.
• Each device derives its own master key from the password.
• Secret block ciphertext syncs safely — it’s encrypted at rest.
• The search index is local-only (rebuilt on each device).

Brute Force Protection

• Wrong password guesses are counted, met with delays that grow after the fifth, and the count survives a restart.
• Argon2id parameters (64 MB memory) make brute-force attacks computationally expensive.
• Biometric unlock supports 3 attempts before falling back to password.

Memory Safety

• Decrypted secret values are deliberately not scrubbed from memory while the vault is open; the lock clears the key, which stops anything new from being decrypted. The public repository’s design note docs/adr/0002 records the reasoning.
• Key material (the master key, password-derived keys, sync group keys and recovery keys) is wrapped in Zeroizing and wiped when the vault locks, on manual lock, auto-lock timeout, or app exit.
• Decrypted secret values are not individually wiped after you reveal them. They live in process memory while the vault is unlocked. Locking wipes the master key, after which nothing further can be decrypted. The reasoning is recorded in the project’s ADR 0002; Claspt does not claim to wipe revealed values, and if you see that claim anywhere it is an error.

Files on disk

The key file, the configuration, the internal store and the MCP client configs Claspt writes are readable by your user account only, on macOS, Linux and Windows.