Map: Threat Models — ungovernable.tech

Threat-modeling rule: name the adversary, name the asset, name the assumption you make about each component. If you cannot write it down, you do not have a threat model. You have hope.

Recurring adversaries

Adversary	Capability	Where it appears
Global passive observer	Wire taps at IXPs, ISP backbones	Overview - Mix Networks, MOC - Metadata Privacy
Cloud provider or hypervisor	Read VM RAM, modify boot, snapshot disk	Overview - Confidential Computing, Cloud-Provider-Comparison
Compromised relay or node	Selective forwarding, traffic injection, dropping	Overview - Mix Networks, Overview - Decentralized Compute
Compromised hardware vendor	Sign attestation reports for arbitrary code	TEE-Side-Channel-Attacks, Attestation-Architecture
Court order or subpoena	Compel logs, key disclosure, code injection	Overview - Encrypted Messaging, MOC - Censorship Resistance
Supply chain attacker	Inject backdoor at build or package time	reproducible builds, transparency logs
51% or Sybil attacker	Outvote consensus, censor blocks	Overview - Financial Sovereignty, Overview - Decentralized DNS
Malicious user device	Full read; export keys	Overview - Identity & Pseudonymity, hardware-wallet patterns
Quantum adversary (future)	Solve DLog and factoring	Overview - Post-Quantum Cryptography

Recurring trust assumptions

When a system claims a property, ask which of these it requires:

Trust the CPU vendor: TEEs require Intel, AMD, or NVIDIA not to misissue attestations.
Trust the CA: TLS without pinning lets any CA mint an MITM cert.
Trust the registrar or DNS path: can be bypassed by self-authenticating names.
Tor separates knowledge across relays; it does not protect against an observer who can correlate both ends of a connection merely because one relay is honest.
Trust the majority of validators: PoS and PoW security models.
Cryptographic constructions have distinct assumptions: FHE and ZK depend on their schemes, while honest-majority MPC explicitly assumes enough non-colluding participants.
Trust your own keys and endpoint: true for everything. If your client is compromised, all bets are off.

Recurring failure modes

Failure mode	Manifests as	Counter
Side-channel leak	Cache timing, page faults, EM	Defense in depth, multi-vendor TEE, oblivious algorithms
Implementation bug	Memory safety, parser issues	Audited primitives, fuzzing, memory-safe languages
Operational mistake	Key reuse, absent pinning	Default-secure tooling, hardware key custody
Protocol downgrade	Negotiate weak parameters	Strict policy in attestation, no fallback
Metadata leak	Even with E2EE	Mixnets, sealed sender, padding
Vendor coercion	Court order to ship signed backdoor	Reproducible builds, transparency logs, multi-signer release
Lost custody	Key destroyed or stolen	Backups, multisig, social recovery

Files with detailed threat models

File	Adversary focus
TEE-Side-Channel-Attacks	Hardware side channels (Foreshadow, CacheWarp, Hertzbleed, ÆPIC)
Confidential-AI-Inference	Inference-specific leaks, oracle adversaries
Overview - Mix Networks	Global observer, compromised mixes
Overview - Encrypted Messaging	Court order, server compromise, social-graph leak
Overview - Financial Sovereignty	Custodial counterparty, chain analysis
Overview - Decentralized DNS	Registrar coercion, DHT poisoning
Overview - Web of Trust	Sybil, key compromise, signing equivocation

New Threat Models

For new threat models, follow the structure of mature security-analysis files in this library and complete every section before adding the note to an index.

Primary sources

Page history

Updated: 2026-10-25
Origin: Compiled from the ungovernable.tech research notes.
Improve this page: Suggest an edit — issues and pull requests are welcome.