Threat Model — ChromVoid

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.

ChromVoid does not promise "unhackability" and does not replace basic security hygiene.

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.

Loading diagram...

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.

Idea: "just copying the folder" is not enough to conveniently run offline brute-force.

Important: this does not replace a strong passphrase. Argon2id + pepper = delay and complication of offline attack, but not an absolute guarantee.

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

ChromVoid publishes these limitations because honesty is part of security.

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.

Loading diagram...

tm_scenario_stolen_title

Attacker tm_scenario_stolen_attacker

Goal tm_scenario_stolen_goal

Attack vector tm_scenario_stolen_vector

Defense tm_scenario_stolen_defense

tm_scenario_stolen_result

tm_scenario_coercion_title

Attacker tm_scenario_coercion_attacker

Goal tm_scenario_coercion_goal

Attack vector tm_scenario_coercion_vector

Defense tm_scenario_coercion_defense

tm_scenario_coercion_result

tm_scenario_mitm_title

Attacker tm_scenario_mitm_attacker

Goal tm_scenario_mitm_goal

Attack vector tm_scenario_mitm_vector

Defense tm_scenario_mitm_defense

tm_scenario_mitm_result

tm_scenario_malware_title

Attacker tm_scenario_malware_attacker

Goal tm_scenario_malware_goal

Attack vector tm_scenario_malware_vector

Defense tm_scenario_malware_defense

tm_scenario_malware_result

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)

Architecture Source Code ↗

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

security@chromvoid.com

Security through honesty