Security

Security is the product, not a feature. These principles apply to every part of llaves.

Envelope encryption

The master key never encrypts your data directly. It only wraps a random data key, and the data key encrypts the content. Rotating your master password re-wraps the data key — the bulk content is never re-encrypted from scratch, and the master key never touches plaintext at rest.

For the vault file itself, llaves follows the standard KDBX scheme exactly, so it stays compatible with every other KeePass app. The envelope model governs our own at-rest key material.

We never hand-roll crypto

AES-256, ChaCha20, Twofish, Argon2, HMAC and secure random all come from vetted libraries. Our code wraps and sequences them; it never reimplements the math. Hand-rolled crypto is how password managers get CVEs.

Zero-knowledge sharing

The share server stores only ciphertext. Encryption and decryption happen on your device (or in your browser), and the decryption key rides in the URL fragment — which browsers never send to the server. Links are burn-after-read with a short expiry. The server literally cannot read what it stores.

Secrets stay in memory

The decrypted vault lives only in memory, never spilled to disk, temp files or swap. llaves locks — dropping keys and clearing buffers — on idle timeout, screen lock and minimize. No vault contents, keys or passwords ever reach logs, crash reports or analytics.

Convenience unlock

On mobile, biometric unlock is opt-in and gated by a hardware-backed key (Android Keystore / iOS Secure Enclave), never by storing your master password. On desktop, llaves does not cache the master key in the OS keyring by default — a security-conscious audience chose local custody, and desktop malware runs as the user.

Threat model

Reporting a vulnerability

Please report security issues privately via coordinated disclosure — see SECURITY.md in the repository — rather than a public issue.