How Argon2id and XChaCha20-Poly1305 actually protect your vault

Most vault and password-manager sites say "military-grade encryption" and leave it there. That phrase describes nothing — AES has been standard since 2001; the question that actually matters is how your password becomes a key, and what happens if that key ever leaks. Here is exactly what Vaultherit does, and why each step exists.

Your password never encrypts anything directly

The first thing to understand: your master password is not the encryption key. When your vault is created, Vaultherit generates one random 256-bit vault key. That key — not your password — is what actually encrypts every record you store. Your password's only job, forever, is to unlock ("unwrap") that one key.

This separation is why you can change your master password without re-encrypting your entire vault, and why up to six independent unlock methods — master password, 24-word recovery phrase, hardware security key, M-of-N multi-factor, a separate family password, and a hidden profile — can each unlock the same data without any of them being a "weaker copy" of it. Each one just wraps its own copy of the same vault key.

Argon2id: turning a password into a key, deliberately slowly

Typing a password is fast. Turning that password into something usable as an encryption key needs to be slow — specifically, slow and memory-hungry, so that brute-forcing it stays impractical even against someone with stolen hardware and unlimited time. Vaultherit uses Argon2id, the current state of the art for this exact job (it won the Password Hashing Competition specifically for resisting both GPU cracking and side-channel attacks), configured at 128 MiB of memory and 3 passes. The memory requirement is the important part: it makes parallelizing an attack across thousands of cheap GPU cores expensive in a way a purely fast, low-memory hash never would be.

XChaCha20-Poly1305: the cipher that actually encrypts your data

Once your vault key is unwrapped, your actual records — the 23 record types across 7 categories, everything from passwords to property documents — are encrypted with XChaCha20-Poly1305, an authenticated encryption (AEAD) cipher via libsodium. "Authenticated" is the operative word: it doesn't just hide the contents, it also detects tampering. If even one byte of an encrypted record is altered — corrupted, or deliberately modified — decryption fails loudly instead of silently returning garbage or, worse, plausible-looking wrong data.

The "X" in XChaCha20 matters too: it extends the nonce (a per-encryption random value that must never repeat) from 96 bits to 192 bits, which all but eliminates the risk of nonce reuse even across a very large number of encryption operations over a vault's lifetime — a real failure mode in ordinary ChaCha20 if nonces are ever generated carelessly.

Zero-knowledge, structurally, not by promise

Vaultherit never sees your master password, and the optional cloud backup only ever stores already-encrypted bytes. This isn't "we promise not to look" — it's that the architecture makes looking impossible. There is no server-side code path that could decrypt your vault, even under a court order, even by mistake.

Want the full technical breakdown, including how the six unlock methods each independently wrap the vault key via BLAKE2b? See the Security page for the live architecture diagram.