Security architecture
Rust/Tauri stack, .rkvey v5 format, compartments, lazy decryption, and threat model.
QubKey security is built on a layered architecture and the principle of defense in depth: the file system, .rkvey v5 format, cryptography, and Rust application core work together to protect your secrets at every step — from storage to unlock.
Each layer provides a complementary guarantee. If a system protection is missing (for example, no disk encryption), the application and cryptographic layers still protect your vault contents. With the v5 format, an entry's secrets are decrypted only when you reveal or copy them — not when the vault opens or when you browse the list.
Interface (React + Tauri)
- Vault
- Folders
- Search
- Generator
- One-time codes
- Dashboard
- Sync
- Sharing
- Browser extension
Rust core (QubKey Core)
- .rkvey v5 format
- Argon2id derivation
- Authenticated encryption
- Search index
- Safe commits
- Memory wipe
- Crash recovery
.rkvey v5 file on the filesystem
- Preamble
- Encrypted header
- Encrypted index
- Secret compartments
- Attachments
- Commit history
Security layers
Unlock flow
Unlock follows a strict pipeline: the master password enters the Rust core, Argon2id derives the master key, then subkeys decrypt the header and B-Tree index. Entry compartments (secrets, attachments) stay encrypted and are read only on demand. On lock, all keys and secrets are wiped from memory.
Master password + Salt
.rkvey preamble (plaintext)
- Entered in Rust core (Tauri IPC) — never exposed to the WebView
- Random salt stored in preamble (16 bytes)
Argon2id
- 64 MB RAM · 3 iter · p=4 (default `KdfParams`)
- GPU / ASIC resistance
- Calibrated ~250–500 ms depending on platform
Master key
256 bits · `KeyManager::derive_master_key`
Subkey derivation
HKDF-SHA256(master, salt=file∥entry, info=kind)
header_key
Secure Header
index_key
B-Tree Index
compartment_key
Compartments
AEAD decryption
- AES-256-GCM or XChaCha20-Poly1305
- Header · Index · Compartments (on demand)
Memory after unlock
- List / view: metadata only
- Secrets and attachments decrypted only on demand
Lock
- `KeyManager::clear_keys()` + zeroize
- Secrets wiped and clipboard cleared
Threat model
QubKey is designed to address the most common threat scenarios for a local manager. The table below describes the attack vector and the corresponding measure built into the product (.rkvey v5 format).
| Threat | Vector | QubKey response |
|---|---|---|
| Unauthorized file access | Theft or copy of .rkvey | AEAD encryption + Argon2id derivation |
| Network exfiltration | Cloud interception / MITM | Local-first: QubKey does not upload your secrets |
| Data corruption | Crash during write | Validated append-only commits + recovery on startup |
| Vault tampering | Manual file modification | Per-compartment AEAD authentication + checksums |
| Memory dump (browsing) | Vault open, list / view | Secrets stay encrypted until you reveal them |
| Weak master password | Offline attempts | Calibrated Argon2id (~500 ms) + entropy meter |
| Password reuse | Leaks on other sites | Security dashboard (local detection) |
| Clipboard leaks | Copying a secret | Clipboard timeout (30 s) + wipe on lock |
| Side-channel attack | Timing on crypto ops | Constant-time implementations (RustCrypto) |
Best practices
This model covers threats QubKey addresses directly through its architecture. For optimal protection, combine QubKey with system best practices: disk encryption enabled, up-to-date OS, and a strong master password.
Built-in protection
| Domain | How QubKey protects your data |
|---|---|
| Data at rest | AEAD encryption (AES-256-GCM / XChaCha20), Argon2id-derived key, unique keys per compartment |
| Vault integrity | Validated append-only commits, checksums, and atomic writes |
| Confidentiality | Zero-knowledge model: your secrets stay encrypted on your device |
| Lazy decryption | List and view without secrets; reveal / copy only on demand |
| Key derivation | Calibrated Argon2id (~500 ms, 64 MB) to strengthen master password protection |
| Application | Isolated Rust core, UI via Tauri IPC, zeroization on lock |
| Browser extension | Local Native Messaging — extension never receives the master password |
| Sync | Opt-in encrypted multi-device sync (QubKey cloud — self-hosting coming soon) or encrypted .rkvey file (cloud, USB, NAS) |
Trust architecture
Zero-knowledge
QubKey organizes trust across complementary levels:
-
You control access — The master password and, if saved, the recovery key control vault access. QubKey cannot read or reset them on your behalf.
-
System integration — QubKey leverages your OS security: file permissions, disk encryption (FileVault, BitLocker, LUKS), secure storage (Keychain, Credential Manager), and process isolation.
-
Rust / UI separation — All cryptography runs in the Rust core with compile-time memory safety. The React UI communicates via Tauri IPC; the WebView never has direct access to the master password.
-
Careful memory handling (v5) — On unlock, only the header and index are decrypted. Secrets and attachments stay encrypted until an explicit action (reveal, copy, download). On lock, secrets are wiped (zeroization) and the clipboard is cleared.
-
Browser extension — Local Native Messaging communication; the extension never receives the master password.
Protection features
Auto-lock
Vault locked after a configurable inactivity period (default: 5 min). Triggers zeroization and clipboard wipe.
Lazy decryption
An entry's secrets are decrypted only when you reveal or copy them. The list and view screens do not expose protected fields.
Zeroization
Secrets wiped from RAM on lock (Rust zeroize crate); caches cleared, ephemeral on-demand decryption only.
Clipboard timeout
Clipboard cleared automatically after 30 seconds. Configurable in vault settings.