Design · Threat model

What veilpass protects, and what it doesn't

Being upfront about the edges of the design is more important than listing everything that works. Here is what a stolen file, a compromised device, or a network observer actually buys an attacker.

The one high-value secret

Veilpass protects the contents of your vault. Nothing else is treated as high-value; every other asset is either non-secret by design (a record key, a DHT address) or low-value metadata whose leakage we mitigate but don't fully prevent (vault size, push cadence).

The threat-model contract is:

1. Only someone with your passphrase can read the vault. Not us. Not Veilid nodes. Not someone who steals the file.
2. Any modification to the vault file surfaces as a decryption failure — silent tampering isn't possible.
3. The vault is a local file. As long as you have the file and the passphrase, you have your data. No outage, no acquisition, no revoked account can take it from you.

Adversaries we consider

1. Someone steals your file

Found your laptop, your phone, or a backup drive. Has the .veilpass file. Wants the credentials inside.

Safe if your passphrase is strong. Every guess costs one Argon2id computation — roughly one second on a phone, hundreds of milliseconds on desktop, and Argon2's memory-hardness undercuts GPU-parallel attack. A five-word EFF passphrase (about 64 bits of entropy) is not brute-forceable outside nation-state resources.

Compromised if your passphrase is weak. A dictionary word or a short passphrase falls in a day.

2. Malware on your unlocked machine

Code running with your privileges, on a device where veilpass is currently unlocked, wants to exfiltrate live credentials.

Outside the threat boundary. A password manager cannot defend against code that already runs as you on your own device. The attacker can read plaintext out of process memory, watch the clipboard, install a keylogger, and screenshot your screen.

Mitigation lives elsewhere. Full-disk encryption, OS sandboxing, browser sandbox integrity, and not running untrusted binaries. Prefer autofill over copy-paste for high-value credentials so the clipboard doesn't see them.

3. A passive Veilid observer

Watching Veilid traffic, or running a Veilid storage node, wants to learn what you're doing. Because Veilid uses onion-style compiled routes (a safety route chosen by the sender, a private route chosen by the destination), these are two very different positions to attack from.

The storage node holding your record. Cannot read the vault — the ciphertext on the DHT is the same AEAD-sealed bytes that live on disk. It can see the record key it is serving, the ciphertext size, and probe cadence. It cannot see who is asking: requests arrive from the last hop of your safety route, never from your real IP, and there is no way for the storage node to link accesses back to a device or a person.

Any other node on the network. Sees only encrypted route packets. Each hop only knows its immediate neighbour; the inner envelope containing the DHT operation and the record key is opaque until it reaches the terminal storage node. A passive network observer cannot see the record key, the ciphertext, or the link between a key and a device. They can still do coarse traffic analysis — packet timing and volume between neighbouring nodes — which, aggregated across enough of the network, can in principle weaken safety-route anonymity. This is a fundamental limitation of any low-latency onion network and is out of scope for veilpass.

4. A compromised paired device

An attacker got read access to a device you'd paired for sync — say, a laptop left at a hotel.

Same passphrase story as case 1. Having a paired device isn't the same as having write access to the vault; write access requires the vault to be unlocked, which requires the passphrase.

Passphrase change is not enough. Because the underlying vault key doesn't rotate on passphrase change, a compromised device that already extracted the vault key keeps its access. If you believe a device is compromised, rotate the vault key on a trusted device and re-pair every other trusted device.

5. Someone intercepts your pairing token

The seven words were transmitted over a channel that turned out to be observable (a screenshot in a chat log, a shoulder surf, an unencrypted SMS).

Compromised. Anyone who reads the token while the sponsor record is still on the DHT can pair as if they were the intended recipient. Treat tokens as one-shot secrets even though the sponsor record isn't auto-deleted; transfer them over channels you trust to not be logged.

Trust anchors

Veilpass's confidentiality assumes:

• Your passphrase isn't disclosed.
• The platform CSPRNG is a real CSPRNG.
• Argon2id, HKDF-SHA-256, and XChaCha20-Poly1305 haven't been broken.
• The OS keychain / keystore isn't silently accessible to other apps.
• Veilid's safety-route implementation correctly hides the publisher's real address.

Non-goals

Common scenarios

Where to report

Please report security issues privately to security@veilpass.io before public disclosure. A longer, code-anchored version of this threat model lives in docs/THREAT_MODEL.md in the repository.