Security Model

Architecture overview

Claspt uses a two-layer encryption architecture. Your master password never directly encrypts data. Instead, it derives a key that decrypts a randomly generated master key, which in turn encrypts individual secret blocks — each with its own unique nonce.

Master Password
      │
      ▼
  Argon2id (64 MB, 3 iter, 4 lanes)
      │
      ▼
  Password-Derived Key (256-bit)
      │
      ├──► Decrypts vault.key  ──►  Master Key (256-bit)
      │                                    │
      │                          ┌─────────┼─────────┐
      │                          ▼         ▼         ▼
      │                      Block 1   Block 2   Block N
      │                     AES-256   AES-256   AES-256
      │                      -GCM      -GCM      -GCM
      │                    (nonce₁)  (nonce₂)  (nonceₙ)
      │
      └──► Biometric Path (optional)
           OS Keychain stores wrapped Master Key

This two-layer design means changing your master password only requires re-encrypting the vault.key file — not re-encrypting every secret block in your vault. Password changes are instantaneous regardless of vault size.

Key derivation: Argon2id

Claspt uses Argon2id — the winner of the 2015 Password Hashing Competition — to derive an encryption key from your master password. Argon2id is specifically designed to resist both GPU-based and side-channel attacks.

At these parameters, deriving a key takes approximately 250–350 ms on a modern laptop (Apple M-series, Intel 12th gen, AMD Zen 4). This is fast enough for interactive use but slow enough that an attacker trying 10 billion passwords would need roughly 95 years on a single machine.

Block encryption: AES-256-GCM

Each secret block is independently encrypted using AES-256-GCM (Galois/Counter Mode). This is an authenticated encryption scheme — it provides both confidentiality and integrity verification in a single operation.

Why per-block encryption?

Most encrypted note apps encrypt the entire file. Claspt encrypts each secret block independently. This means:

• Selective encryption. Your markdown notes stay searchable and readable. Only the sensitive data (credentials, keys, card numbers) is encrypted.
• Granular access. Unlocking one secret does not expose others. Each block requires independent decryption.
• Efficient sync. When you change one secret, only that block's ciphertext changes — not the entire file. This minimises sync conflicts and bandwidth.
• Unique nonces. Each block has its own 96-bit nonce, generated fresh on every encrypt operation. Two blocks never share a nonce, even if they contain identical plaintext.

Why not XChaCha20-Poly1305?

AES-256-GCM has hardware acceleration (AES-NI) on virtually all modern CPUs, giving 2–5x throughput over software ChaCha20. For a desktop application where hardware support is guaranteed, AES-GCM is the pragmatic choice. Both algorithms provide equivalent security margins at their respective key sizes.

The vault.key file

The vault.key file is the single most important file in your vault. It contains:

┌──────────────────────────────────┐
│  vault.key file structure        │
├──────────────────────────────────┤
│  Version     (1 byte)            │
│  Argon2 salt (16 bytes)          │
│  Argon2 params (memory, iter,    │
│    parallelism) (12 bytes)       │
│  Encrypted master key (48 bytes) │
│    └─ 32-byte key + 16-byte tag  │
│  Nonce for master key (12 bytes) │
└──────────────────────────────────┘

• The master key is 256 bits, randomly generated once at vault creation. It never changes unless you explicitly rotate it.
• The master key is encrypted with the password-derived key (from Argon2id).
• If the vault.key file is deleted or corrupted, and you have no backup, your encrypted secrets are permanently lost. The file is small enough to back up trivially.
• The salt and Argon2 parameters are stored alongside the encrypted key so Claspt can re-derive the password-derived key on unlock.

What's encrypted vs plaintext

Claspt is a selective encryption system, not a full-disk encryption system. This is a deliberate design choice.

Why not encrypt everything? Full-file encryption prevents search, prevents sync diffing, prevents using standard markdown tools, and prevents you from reading your own notes without launching Claspt. Selective encryption gives you the security of a password manager with the usability of a note-taking app.

Memory handling

Sensitive data in memory is a potential attack surface. Claspt takes these precautions:

• Zeroing on lock. When a secret block is locked (manually, on timer, or on app background), the decrypted plaintext is overwritten with zeros in memory before deallocation.
• Rust memory safety. Claspt's encryption core is written in Rust with the zeroize crate, which guarantees compiler optimisations do not elide the zero-fill operations.
• Password-derived key lifetime. The password-derived key is used only to decrypt the master key, then immediately zeroed. It is not cached.
• Master key in protected memory. On macOS and Windows, the decrypted master key is held in memory pages marked as non-swappable where the OS supports it, reducing the risk of key material being written to disk via swap.

Biometric key storage

When biometric unlock is enabled, a wrapped copy of the master key is stored in the operating system's secure credential store:

Claspt never accesses your biometric data directly. It delegates authentication entirely to the operating system and receives a boolean pass/fail result. Your fingerprint or face data stays in the Secure Enclave / TPM and is never exposed to the application.

Threat model

A threat model defines what Claspt protects against and what it does not. Being honest about limitations is more valuable than vague claims of "military-grade security."

Claspt protects against:

• Stolen device (powered off). An attacker with your laptop's SSD cannot read encrypted secrets without your master password. Brute-forcing is impractical due to Argon2id's memory-hard parameters.
• Sync server compromise. If your Git remote, WebDAV server, or cloud storage is breached, attackers get encrypted blobs. The master key never leaves your device. Decryption requires your master password.
• Shared link interception. Shared links use end-to-end encryption. The decryption key is in the URL fragment (after #) which is never sent to the server.
• Casual physical access. Someone briefly using your unlocked computer cannot read secrets if you have auto-lock enabled (default: 60 seconds).

Claspt does NOT protect against:

• Compromised device (malware). If an attacker has persistent code execution on your machine (keylogger, screen recorder, memory dumper), no application-level encryption is sufficient. This is a fundamental limitation of all software encryption.
• Weak master password. If your password is "password123", Argon2id slows down brute-force but does not make it impossible. Use a strong password.
• Physical access to an unlocked vault. If Claspt is running and unlocked, secrets are decryptable. Lock your vault when stepping away.
• Metadata analysis. File names, folder structure, page titles, and markdown content are plaintext. An attacker with file access can see what topics you have notes about, even if they cannot read the secrets within.
• Rubber-hose cryptanalysis. No encryption protects against being forced to reveal your password.

Known limitations

• No independent audit. As of February 2026, Claspt's encryption implementation has not been audited by a third-party security firm. We intend to commission an audit as resources allow. The security page on this website will be updated when an audit is completed.
• No key rotation without re-encryption. Changing your master password re-encrypts the vault.key file. Rotating the actual master key requires decrypting and re-encrypting every secret block. Claspt does not yet offer one-click master key rotation.
• No plausible deniability. The presence of vault.key and encrypted blocks is visible to anyone with file access. There is no hidden volume or decoy vault feature.
• Swap file risk on Linux. On Linux without encrypted swap, decrypted key material in memory could theoretically be written to disk. We recommend using encrypted swap or disabling swap on security-critical machines.