Security through honesty
What ChromVoid protects, what it doesn't, and why we publish limitations.
What ChromVoid protects
ChromVoid is designed for storing passwords, OTP, notes and other secrets with a threat model where physical access, coercion, network attacks, and offline analysis are possible.
Critical assets and metadata
| Asset | Description | Impact if compromised |
|---|---|---|
| Secrets in vault | Passwords, keys, TOTP seeds, files | Full account compromise |
| Vault password | Password to open a vault | Access to all secrets in that vault |
| Master key | Root of trust for storage | Backup/restore, pairing, erase — but NOT data access |
| Device private key | Noise Protocol key for the current host | Transport channel compromise |
| Session keys | Active Noise session keys | Current traffic decryption |
Sensitive metadata
| Metadata | Protection |
|---|---|
| Vault count | Hidden (Plausible Deniability) |
| Records per vault | Hidden until unlock (encrypted catalog) |
| Last access time | Partially — FS timestamps visible |
| Storage size | Visible (total chunk size) |
| Directory structure | Hidden (flat chunk structure) |
Trust boundaries
ChromVoid is built as a zero-trust system. No component is "trusted by default". Access is granted through capability grants. All communication is encrypted end-to-end: Noise over USB/WebRTC DataChannel/WSS via Relay.
Trust zones and levels
| Zone | Trust level | Rationale |
|---|---|---|
| Core Zone | Full | Rust code, verified cryptography |
| Client Zone (Tauri) | High | Controlled code, but vulnerable to host malware |
| Browser Extension | Medium | Isolated context, but less control |
| Network | Zero | Always considered compromised |
| Physical device access | Accepted risk | Not protected from physical access |
Operating modes
- Local mode: Rust Core built into Desktop/Mobile
- Mobile host: Phone is source of truth (Secure Enclave/TEE), Desktop connects via USB or WebRTC/WSS
- Desktop + Extension: the browser extension connects through Desktop Gateway on localhost; secrets stay in the Desktop app
- Relay path: paired clients can communicate over WebRTC/WSS with end-to-end encrypted transport
Cryptography
Standard cryptographic primitives with no proprietary algorithms. Everything is documented and verifiable.
Primitives and usage
| Primitive | Usage | Context |
|---|---|---|
| ChaCha20-Poly1305 | AEAD data encryption | At rest |
| Argon2id | Memory-hard KDF for password-based key derivation | At rest |
| BLAKE3 | Hashing and auxiliary material derivation | At rest |
| Noise Protocol (XX/IK/XXpsk0) | End-to-end encryption over all channels | In transit (USB / WebRTC / WSS) |
| X25519 | Key exchange within Noise | In transit |
Storage architecture
ChromVoid uses chunk-based storage. Data is stored as encrypted chunks (~16KB). Each chunk is encrypted separately. Writes are atomic (write-temp-rename) + fsync.
Storage security properties
- Each chunk encrypted independently — simplifies sync, reduces structure "chattiness"
- AAD = chunk name — protection against swap/chunk substitution attacks
- Atomic writes (write-temp-rename) + fsync for crash resilience
- Sharded catalog — domains separated (.passmanager, .wallet, .files)
- Delta sync — only changed chunks are transferred
Offline-hardening
When an attacker has a copy of your files, ChromVoid applies a "separate data and hardening material" approach. Storage data (chunks) is in the filesystem. An additional secret (storage pepper) is stored separately (e.g., in OS keystore) and participates in key derivation.
Plausible Deniability
ChromVoid supports a decoy vault + hidden vaults model: no obvious "wrong password" signal, minimal metadata about vault count, hidden data boundaries at storage level (flat chunk approach).
Limitations (important to read)
- Depends on attack class: single-snapshot vs multi-snapshot analysis
- Storage medium properties may leave write traces/remnants
- Your habits (OPSEC): decoy plausibility, usage regularity, structure "explainability"
- Does not hide that ChromVoid is installed or the total data size
Threat actors
ChromVoid defends against a range of adversaries — from opportunistic thieves to nation-state actors. Different threat levels require different operating modes.
Attacker profiles
| Actor | Resources | Motivation | Typical attacks |
|---|---|---|---|
| Script kiddie | Low | Curiosity | Public exploits, phishing |
| Cybercriminal | Medium | Financial | Malware, credential theft |
| Nation-state | High | Intelligence | 0-day, supply chain, rubber hose |
| Insider | Medium | Various | Social engineering, physical access |
Attack scenarios
Concrete scenarios help understand how ChromVoid's defenses work in practice. Each scenario describes the attacker, their goal, the attack vector, and the protection outcome.
What we don't protect
Honest disclosure of limitations is part of our security approach. These are accepted risks.
- Host compromise during unlock: if the OS is infected and reads screen/keyboard/memory while the vault is open, the risk is high for any password manager.
- Weak passwords: KDF slows down brute-force but doesn't make the password strong.
- Social engineering and user errors: transferring secrets to notes/screenshots/chat.
- Physical access to an unlocked host device: software-only protection does not stop direct inspection or memory extraction.
- Supply-chain compromise of the host OS, firmware, or device hardware is outside the scope of this threat model.
Recommendations
Practical guidance to maximize ChromVoid's protection.
- Critical Use a strong passphrase (4-5 words or ≥12 characters)
- Important Keep decoy vault plausible and "explainable"
- Important Prefer localhost or direct cable paths when they are available
- Critical Enable auto-lock and lock on sleep
- Critical Store master_password on paper in a secure place
- Important Make regular encrypted backups
- Recommended Keep the application updated
Auditability
ChromVoid's architecture is open and documented. You can verify the security claims yourself.
- Architecture diagrams for core, transport, and trust boundaries
- Public repo and protocol specs
- API specification (OpenAPI)
Responsible Disclosure
If you find a vulnerability, please report it responsibly.
- Do not publish PoC publicly before the fix
- Write to security@chromvoid.com or via GitHub Security Advisories
- We will confirm receipt and provide status updates