The Claspt Security Model, Explained —
No Black Boxes

Most security pages say "military-grade encryption" and stop there. That phrase means nothing. AES-256 is used by everyone from banks to messaging apps. The real question is not which cipher but how the system uses it. Here is exactly what happens to your data in Claspt.

The Key Hierarchy

Claspt uses a three-layer key hierarchy. Understanding this chain is the single most important thing for evaluating whether you trust the system. Here is the entire chain, from your master password to the ciphertext on disk:

Why the indirection through vault.key? Because it lets you change your master password without re-encrypting every secret in the vault. When you change your password, only vault.key is re-encrypted. The master key inside it stays the same, so all your existing encrypted blocks remain untouched.

Why AES-256-GCM

AES-256-GCM is not exotic. It is the same cipher used by HTTPS when you connect to your bank. It is used by Signal, WhatsApp, government systems, and every serious encryption library. We chose it precisely because it is boring. Boring cryptography is good cryptography. It means decades of scrutiny, no known practical attacks, and widespread hardware acceleration on modern CPUs.

The "GCM" part matters. GCM is an authenticated encryption mode, which means it does not just encrypt your data — it also verifies that the ciphertext has not been tampered with. If someone modifies even a single bit of an encrypted block on disk, decryption will fail entirely rather than producing corrupted plaintext. This protects against both accidental corruption and deliberate tampering.

Why Argon2id Over bcrypt or PBKDF2

Your master password is the weakest link in the chain. If an attacker gets your vault files, they will try to brute-force your password. The key derivation function determines how expensive each guess is.

PBKDF2 is CPU-only. An attacker with a modern GPU farm can run billions of PBKDF2 hashes per second. bcrypt is better — it uses a modest amount of memory — but it was designed in 1999 and does not fully exploit the memory bottleneck.

Argon2id is memory-hard. Claspt's configuration requires 64 MB of RAM per derivation with 3 iterations. This means each password guess requires allocating and filling 64 MB of memory. GPUs have enormous parallel throughput for math operations, but they have limited per-core memory. An attacker running Argon2id on a GPU cannot parallelize thousands of attempts because each attempt needs its own 64 MB allocation. ASICs face the same constraint. Memory is expensive, and memory bandwidth is the bottleneck that Argon2id exploits.

The "id" variant of Argon2 combines both data-dependent (Argon2d) and data-independent (Argon2i) memory access patterns, providing resistance against both GPU/ASIC attacks and side-channel attacks.

Per-Block Nonces

Every secret block in your vault is encrypted with the same master key but a different 96-bit random nonce. This means that if you store the same password in two different pages, the ciphertext will be completely different. An observer cannot determine whether two blocks contain the same plaintext. The nonce is stored alongside the ciphertext — it does not need to be secret, only unique.

The Secret Block Syntax

In your markdown files, a secret block looks like this when you are editing:

:::secret[Production Database]
host:     db.example.com
port:     5432
user:     app_prod
password: s3cure-p@ssw0rd-here
:::

On disk, after saving, the same block looks like this:

:::secret[Production Database]
enc:v1:SGVsbG8gV29ybGQhIFRoaXMgaXMgYSBiYXNlNjQg
ZW5jb2RlZCBzdHJpbmcgdGhhdCByZXByZXNlbnRzIHRoZSBl
bmNyeXB0ZWQgY2lwaGVydGV4dCBvZiB5b3VyIHNlY3JldA==
:::

The label "Production Database" stays plaintext — it is part of the page structure, not a secret itself. The contents are replaced with a versioned, base64-encoded ciphertext. The v1 prefix identifies the encryption scheme version, allowing future upgrades without breaking existing vaults.

What Is NOT Encrypted

This is a deliberate design choice, not a limitation. The following stay plaintext:

• Page titles — so you can find your pages without decrypting the vault.
• Folder names — so your file system structure is navigable.
• Non-secret content — your markdown notes, headings, code snippets, checklists.
• Secret block labels — so you know what a block contains without decrypting it.
• File metadata — modification times, file sizes, Git history.

This is what makes Claspt's vault portable and searchable. You can grep for "AWS" across your vault and find the right page without touching the encryption layer. You can look at a Git diff and see that you added a new section to your notes. Full-vault encryption makes all of this impossible.

Memory Safety: Rust and zeroize

The encryption and decryption logic runs in Rust, not JavaScript. Rust prevents buffer overflows, use-after-free, and dangling pointer bugs at compile time. There is no garbage collector deciding when to clean up decrypted data. When Claspt decrypts a secret block for display, the plaintext is held in a zeroize-protected buffer. The moment the secret is hidden again or the app locks, the buffer is overwritten with zeros. This is deterministic — it happens immediately, not at some future GC cycle.

In a JavaScript-based app (Electron, for example), decrypted strings live on the heap and are cleaned up whenever the V8 garbage collector runs. That could be seconds or minutes later. In Rust, the memory lifetime is explicit and enforced by the compiler.

Sync Safety

The vault.key file never leaves your device. It is excluded from sync and from Git. Each device you use Claspt on derives its own copy of vault.key from your master password. The encrypted markdown files — your actual vault content — sync freely through iCloud, Dropbox, Git, or whatever method you choose. Even if your sync provider is breached, the attacker gets only the encrypted ciphertext, not the key.

Threat Model

Security claims are meaningless without a threat model. Here is what Claspt protects against and what it does not:

Someone steals your laptop

If your device is stolen while locked, the attacker has your encrypted vault files. Without your master password, they must brute-force Argon2id (64 MB memory, 3 iterations) for every guess. A strong master password (4+ random words or 16+ characters) makes this infeasible for decades.

Your cloud sync is breached

The attacker gets your .md files with encrypted blocks. They can read your non-secret notes but cannot decrypt the secret blocks without vault.key, which is never synced. This is the same threat model as storing an encrypted file on Dropbox.

An attacker with physical access while the app is unlocked

If someone has your device while Claspt is unlocked and the screen is visible, they can see any secret you reveal. This is true of every security tool. Claspt mitigates this with auto-lock timers and biometric re-authentication for secret reveals.

A malicious Claspt update

If we were compromised and shipped a malicious build, it could exfiltrate your data. This is true of any closed-source software. We mitigate this with reproducible builds and signed binaries. The encryption code is open-source and auditable.

Security Should Not Require Trust

We wrote this article because we believe security should be verifiable, not a marketing claim. Every design decision described here is implemented in code you can inspect. There are no black boxes, no proprietary encryption schemes, no "just trust us." The algorithms are standard. The implementations are auditable. The threat model is honest about its boundaries.

If you find a flaw, we want to know. Security is not a state — it is a process.