Threat Model

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.

This model is scoped to defined conditions: encrypted storage at rest, strong credentials, and a host that is not actively observing the open vault.

Show details

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. Components are not trusted by default; access is granted through capability grants. Remote RPC/data payloads are protected with Noise over approved transport paths, while local Tauri IPC stays inside the app boundary.

Show details

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); Mobile MVP uses WSS Relay + Noise, with WebRTC/USB as separate spec-gated paths
Desktop + Extension: the browser extension connects through Desktop Gateway on localhost; secrets stay in the Desktop app
Network remote: paired clients follow the approved WebRTC/WSS policy; payload data is protected end-to-end with Noise

Cryptography

Standard cryptographic primitives with no proprietary algorithms. Everything is documented and verifiable.

Show details

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.

Show details

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 by internal namespace
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).

Show details

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.

Show details

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.

Show details

Copied storage

AttackerSomeone with a copy of vault files, a backup, or the disk

GoalRecover vault contents offline

Attack vectorCopies encrypted storage and tries to test password candidates outside the normal unlock path

DefenseData remains encrypted; unlock depends on the vault password, Argon2id, and hardening material that should not sit next to a copied storage directory.

An offline copy does not become an open vault. Size, storage layout, timestamps, and weak-password or leaked-storage-pepper risks remain.

Coerced disclosure

AttackerA person or organization demanding to see vault contents

GoalGet evidence that no other secrets exist

Attack vectorForces the user to unlock ChromVoid, show data, or hand over a password

DefenseDeniability uses controlled disclosure: a decoy password opens a plausible vault, while hidden surfaces are not shown as a separate vault list.

This reduces obvious signs of hidden data, but does not remove OPSEC, live-observation, repeated-snapshot, or storage-analysis risks.

MITM on a remote path

AttackerA network observer, relay, or intermediary between client and host

GoalRead RPC, impersonate a host, or inject commands

Attack vectorIntercepts WebRTC/WSS/USB transport, replays messages, or tries to impersonate a paired peer

DefenseThe remote path uses Noise with paired-key authentication; transport readiness does not open the dashboard until the host vault is unlocked.

An unpaired or impersonated peer should be rejected before secret access. Relay remains a transport layer and does not become source of truth.

Malware on an unlocked host

AttackerA malicious process, keylogger, screen capture tool, or extension on an already compromised device

GoalCapture secrets during an open session

Attack vectorObserves input, screen, clipboard, process memory, or UI after unlock

DefenseChromVoid limits secret storage in the browser, uses short-lived grants, and separates browser, desktop, and host roles.

This is not protection from a fully compromised live host. In that state the Threat Model boundary is already broken; OS hardening, hygiene, and locking the vault outside the active session are required.

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.

CriticalUse a strong passphrase (4-5 words or ≥12 characters)
ImportantKeep decoy vault plausible and "explainable"
ImportantPrefer localhost or direct cable paths when they are available
CriticalEnable auto-lock and lock on sleep
CriticalStore master_password on paper in a secure place
ImportantMake regular encrypted backups
RecommendedKeep 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