Formal Threat Model

A cryptographic system without an explicit threat model is a system making implicit claims it cannot justify. The statement "Zentalk is secure" is meaningless without a precise specification of the adversaries it is secure against, the assumptions under which those guarantees hold, and the conditions under which they fail. Security is not a binary property. It is a relation between a system, an adversary class, and a set of assumptions. This chapter defines that relation for Zentachain with the rigor expected of a formal security analysis.

The threat model serves three functions. First, it establishes the adversary categories against which the system provides protection, ranging from passive observers to nation-state actors with global traffic visibility. Second, it enumerates the precise security guarantees the system offers and the cryptographic or architectural mechanisms that enforce each guarantee. Third -- and most critically -- it states explicitly what the system does not protect against. A threat model that acknowledges only strengths is marketing, not security analysis. The honest enumeration of limitations is what distinguishes a credible threat model from an aspirational one.

Adversary Categories

The following taxonomy classifies adversaries by capability, from least to most powerful. For each category, the analysis specifies: what the adversary can observe, what actions the adversary can take, what information remains protected, and the degree of protection Zentachain provides. These categories are not mutually exclusive -- a real-world adversary may combine capabilities from multiple categories.

Category 1: Honest-but-Curious Validator

Definition. An honest-but-curious (semi-honest) validator follows the protocol specification correctly -- it stores data as instructed, forwards messages as required, and participates in consensus honestly -- but attempts to extract as much information as possible from the data it legitimately observes in the course of honest operation.

Observable information:

• Encrypted message ciphertexts (AES-256-GCM encrypted payloads)
• Routing headers, including hashed recipient addresses (zh1_ scheme)
• Connection timing: when users connect, disconnect, and transmit data
• IP addresses of directly connected clients
• Message sizes and transmission frequencies
• Sealed sender blobs (opaque to the validator)

Information protected from this adversary:

• Plaintext message content (protected by AES-256-GCM under the Double Ratchet)
• Sender identity for direct messages (protected by the sealed sender protocol; the validator sees only the ephemeral X25519 public key, not the sender's address)
• Recipient real-world identity (protected by address hashing; the validator sees zh1_ hashes, not wallet addresses)
• Correspondence between hashed addresses and wallet addresses (protected by SHA-256 preimage resistance)
• Message content type -- text, media, voice (protected by fixed-size relay cells of 542 bytes)

Protection level: Full. All primary security properties -- confidentiality, integrity, authenticity, sender privacy, and recipient unlinkability -- hold against this adversary. The honest-but-curious validator represents the baseline adversary model for which Zentachain provides comprehensive protection. The cryptographic guarantees are mathematical: breaking them requires breaking AES-256-GCM, X25519, Ed25519, or SHA-256, each of which is computationally infeasible under standard assumptions.

Category 2: Malicious Validator (Single Node)

Definition. A malicious validator controls one node in the network and deviates arbitrarily from the protocol. Unlike the honest-but-curious adversary, the malicious validator may actively interfere with the system's operation.

Adversary capabilities:

• All observational capabilities of Category 1
• Drop messages selectively or entirely, denying service to specific users
• Delay message delivery to disrupt communication or enable timing attacks
• Log all metadata passing through the controlled node, building dossiers of communication patterns
• Attempt traffic analysis by correlating message arrival and departure times
• Inject malformed or replayed messages into the network
• Refuse to store or serve erasure-coded data fragments
• Provide false responses to data retrieval requests

Actions the adversary cannot take:

• Decrypt message content. Without the recipient's Double Ratchet session keys, the ciphertext is computationally indistinguishable from random noise. AES-256-GCM provides IND-CCA2 security.
• Forge messages from other users. Message authenticity is enforced by Ed25519 signatures on key bundles and GCM authentication tags on individual messages. Forging a signature requires solving the elliptic curve discrete logarithm problem on Curve25519, which requires approximately $2^{128}$ operations.
• Impersonate users during key exchange. The X3DH key agreement protocol authenticates both parties through their long-term identity keys. A man-in-the-middle attack is detectable through safety number verification.
• Unseal sealed sender blobs. Decrypting a sealed sender requires the recipient's X25519 private key, which never leaves the recipient's device.
• Reverse address hashes to obtain wallet addresses. SHA-256 preimage resistance requires $O(2^{256})$ operations.

Protection mechanisms and their effectiveness:

Threat	Protection	Mechanism
Message dropping	Detected, economically punished	Delivery receipts; honest validators provide alternative routing paths; slashing of staked CHAIN tokens upon detection
Message delay	Partially mitigated	Timeout-based retransmission; multi-path delivery through alternative validators
Metadata logging	Structurally limited	The single node sees only its own traffic fraction; sealed sender hides sender identity; address hashing obscures recipient identity
Traffic analysis	Mitigated by architecture	Multi-hop relay routing ensures the malicious node sees at most one hop; timing obfuscation (exponential delay, mean 100ms) decorrelates message timing
Data withholding	Mitigated by redundancy	Reed-Solomon erasure coding distributes data across multiple nodes; retrieval succeeds as long as a sufficient subset of nodes cooperates
Message injection	Detected and rejected	GCM authentication tags reject tampered ciphertext; Ed25519 signatures reject forged key bundles; replay detection via message IDs

Protection level: High. Content confidentiality, integrity, and authenticity are mathematically guaranteed. Availability is architecturally protected through redundancy and economic incentives but is not unconditionally guaranteed -- a sufficiently targeted denial-of-service attack by a single malicious validator can degrade service for users whose traffic routes exclusively through the compromised node. The economic slashing mechanism makes sustained misbehavior expensive: a validator must stake CHAIN tokens to participate, and detectable protocol violations result in partial or total stake confiscation.

Category 3: Colluding Validators (f < n/3)

Definition. Multiple validator nodes, controlled by a single adversary or operating in coordination, cooperate to attack the network. The threat model assumes that fewer than one-third of all validators are adversarial, consistent with the Byzantine fault tolerance threshold required for the network's consensus mechanism.

Adversary capabilities (in addition to Category 2):

• Correlate traffic across all controlled nodes, observing a larger fraction of the network's message flow
• Attempt to de-anonymize multi-hop relay routes by controlling multiple hops in a single circuit. If the adversary controls both the entry (Guard) and exit relay in a three-hop circuit, it can correlate the sender's IP address with the recipient's address.
• Coordinate message dropping or delaying to target specific users more effectively
• Attempt Sybil attacks by deploying additional validator nodes to increase network presence

Information that remains protected:

• Message content. E2EE is independent of the number of compromised validators. Even if every validator in the network is compromised, message confidentiality holds because validators never possess decryption keys.
• Sealed sender privacy, unless the colluding validators control all hops in a relay circuit and the recipient's home relay. Breaking sealed sender requires the recipient's X25519 private key, which colluding validators do not possess.
• Forward secrecy. Compromising validators provides no access to past message keys, which are deleted after use by the Double Ratchet.

Protection mechanisms:

• Multi-hop relay diversity. Relay circuits are constructed across diverse operators. The probability that an adversary controlling a fraction $f$ of $n$ validators controls both the Guard and Exit relays of a random three-hop circuit is approximately $(f/n)^2$. For $f < n/3$, this probability is less than $1/9$ per circuit.
• Sybil resistance through staking. Each validator must stake CHAIN tokens. Deploying $k$ additional validators requires $k$ times the minimum stake, making large-scale Sybil attacks economically expensive. The cost of controlling one-third of the network scales linearly with the total staked value.
• Circuit rotation. Relay circuits are periodically rotated, limiting the duration of any correlation advantage gained by controlling specific hops.

Honest limitation: If colluding validators happen to control both the Guard and Exit relays of a specific circuit, they can correlate the sender's IP address with the recipient's hashed address for messages on that circuit. The probability of this event decreases with network size and validator diversity, but it is not zero. Zentachain does not claim unconditional anonymity against colluding minorities.

Protection level: Moderate to High. Content security remains mathematical and unconditional. Metadata protection degrades probabilistically as the fraction of compromised validators increases. The economic cost of collusion (proportional to staked capital) and the architectural diversity of relay circuit selection limit the practical effectiveness of this attack.

Category 4: Global Passive Adversary (Nation-State Surveillance)

Definition. An adversary with the capability to observe all network traffic between all nodes in the Zentachain network simultaneously. This is the canonical nation-state adversary model, exemplified by programs such as NSA's PRISM and GCHQ's Tempora, which intercept traffic at the fiber-optic backbone level. The adversary is passive -- it observes but does not modify traffic.

Adversary capabilities:

• Observe all encrypted traffic entering and exiting every node in the network
• Perform end-to-end timing correlation: if a message enters the network from Alice's IP address at time $t$ and a message exits the network to Bob's IP address at time $t + \Delta$, the adversary can hypothesize a communication link between Alice and Bob
• Perform volume analysis: correlate bursts of traffic from one IP address with bursts arriving at another
• Perform long-term traffic pattern analysis: build statistical models of communication patterns over weeks or months
• Identify all IP addresses communicating with the Zentachain network (unless users employ Tor or VPN)

Information that remains protected:

• Message content. AES-256-GCM encryption under the Double Ratchet is independent of network-level observation. The global passive adversary sees only ciphertext. Breaking it requires breaking AES-256, which requires $O(2^{256})$ operations classically and $O(2^{128})$ operations with Grover's algorithm -- both far beyond any foreseeable computational capability.
• Sender identity within messages. The sealed sender protocol encrypts the sender's address within the message payload. The global observer can see the originating IP address but cannot link it to a specific Zentalk identity without additional information.
• Address-to-identity mapping. Hashed addresses (zh1_) prevent the global observer from linking network traffic to specific wallet addresses or real-world identities (subject to the limitations of deterministic hashing noted in Chapter 3).

Information partially protected:

• Communication patterns. Multi-hop relay routing forces traffic through three intermediate hops with layered encryption. The global observer cannot trivially determine message routes by inspecting encrypted payloads. However, sophisticated timing correlation -- analyzing the time at which encrypted packets enter the first hop and exit the last hop -- can probabilistically link sender and recipient.
• Activity timing. Fixed-rate cover traffic (PADDING cells at 2-10 cells/second) and timing obfuscation (exponential random delays, mean 100ms, capped at 500ms) add noise to timing signals. This reduces the accuracy of timing correlation but does not eliminate it.

Honest limitation. Zentachain does not claim full protection against a global passive adversary. Achieving provable anonymity against such an adversary requires a mix network with constant-rate cover traffic across all participants -- a design that imposes severe latency and bandwidth costs incompatible with real-time messaging. Systems that do claim this level of protection, such as Loopix or Nym, accept multi-second message latencies as a necessary trade-off.

Zentachain's design prioritizes practical usability (sub-300ms delivery latency) while providing meaningful -- but not absolute -- protection against traffic analysis. The multi-hop relay architecture, fixed-size cells, timing obfuscation, and cover traffic collectively raise the cost and reduce the reliability of timing correlation attacks, but a sufficiently resourced adversary with persistent global observation capability can, over time, develop probabilistic models of communication patterns.

Recommended user mitigation. Users facing nation-state adversaries should route all Zentalk connections through the Tor network, which provides an additional layer of IP address obfuscation and traffic mixing independent of Zentachain's relay architecture.

Protection level: Partial. Content confidentiality is fully and unconditionally protected. Metadata protection is meaningful but not absolute. Timing analysis is partially mitigated, not eliminated. This is an honest assessment consistent with the state of the art in anonymous communication research.

Category 5: Active Network Adversary

Definition. An adversary who can not only observe but also modify, drop, delay, reorder, or inject network packets between any pair of nodes. This models a compromised ISP, a hostile WiFi access point operator, or a government exercising active network manipulation capabilities.

Adversary capabilities:

• All observational capabilities of Category 4
• Drop or delay specific packets to disrupt communication or force protocol fallbacks
• Inject forged packets into network connections
• Attempt man-in-the-middle (MITM) attacks on key exchange by intercepting and modifying public key material
• Perform denial of service by flooding nodes with traffic
• Attempt downgrade attacks to force weaker cryptographic parameters

Information and properties that remain protected:

• Transport confidentiality. All node-to-node communication is protected by TLS 1.3, which provides authenticated encryption with forward secrecy. An active adversary cannot decrypt TLS-protected traffic or inject data into an established TLS session without detection. TLS 1.3 eliminates the vulnerable renegotiation and downgrade paths present in earlier TLS versions.
• Message authenticity. Ed25519 signatures on X3DH key bundles (identity key, signed prekey, one-time prekeys) prevent forgery. An adversary who intercepts a key bundle cannot modify it without invalidating the signature. Forging an Ed25519 signature requires $O(2^{128})$ operations.
• Key exchange integrity. The X3DH protocol authenticates both parties through their long-term identity keys. A MITM attacker who substitutes their own public key produces a different shared secret, which results in a different safety number. Users who verify safety numbers (through QR code scanning or manual comparison) detect MITM attacks with certainty.
• Replay prevention. One-time prekeys in X3DH ensure that replaying a captured key exchange handshake does not establish a valid session. GCM nonces and message sequence numbers prevent replay of individual messages.

Adversary's effective attacks:

Attack	Impact	Mitigation
Denial of service (packet dropping)	Temporary communication disruption	Multi-path routing through alternative validators; offline message queuing with 30-day TTL
Denial of service (traffic flooding)	Node or network overload	Rate limiting; RLN-based anonymous rate enforcement; validator resource provisioning
MITM on key exchange (without safety number verification)	Adversary can read messages in the compromised session	Safety number verification detects MITM; key transparency logs (planned) provide automated MITM detection
Connection metadata observation	IP addresses and connection timing exposed	Tor/VPN for IP obfuscation; TLS 1.3 hides application-layer metadata from network observers

Honest limitation. If users do not verify safety numbers, a MITM attack on the initial key exchange can succeed. The adversary would intercept Alice's key bundle, substitute their own, and establish separate encrypted sessions with Alice and Bob, relaying messages between them. This attack is undetectable without out-of-band safety number verification. Zentachain strongly recommends safety number verification for high-security contacts and is developing key transparency mechanisms for automated detection.

Protection level: High. TLS 1.3 defeats active network manipulation of transport-layer traffic. Ed25519 signatures defeat forgery of key material. Safety number verification defeats MITM attacks on key exchange. The primary residual risk is denial of service, which is mitigated architecturally but cannot be unconditionally prevented against a sufficiently resourced adversary.

Category 6: Compromised Client Device

Definition. An adversary who gains physical or remote access to a user's device -- through theft, confiscation, malware, or exploitation of an operating system or browser vulnerability.

Adversary capabilities:

• Read all data stored on the device, including messages cached in IndexedDB, cryptographic keys in memory or storage, contact lists, group memberships, and media files
• Extract Double Ratchet session state, including current chain keys and message keys
• Observe all future messages in real-time until the compromise is detected and remediated
• Potentially extract the user's long-term identity private key, enabling impersonation

Information that remains protected:

• Messages already deleted. The Double Ratchet protocol's forward secrecy guarantee means that message keys are deleted after use. A message decrypted and then deleted from the device cannot be recovered, because the key used to decrypt it no longer exists. The adversary gains access to messages currently stored on the device but not to messages that were previously received and deleted.
• Messages on other users' devices. Compromising Alice's device does not compromise messages stored on Bob's device. Each participant maintains independent key state.
• Future messages after re-keying. When the Double Ratchet advances through a Diffie-Hellman ratchet step (triggered by the other party sending a message), new chain keys are derived that are computationally independent of the compromised state. This post-compromise security property means that the adversary's window of access is bounded: once both parties have exchanged new DH ratchet values, the adversary loses the ability to decrypt subsequent messages.

Protection mechanisms on the device:

Mechanism	Protection Provided	Limitation
IndexedDB encryption (AES-256-GCM)	Data at rest is encrypted; casual access to the file system does not reveal plaintext	The encryption key must be available in memory for the application to function; a sophisticated adversary with memory access can extract it
PIN/biometric lock	Prevents casual unauthorized access to the application	Bypassable by an adversary with device root access or OS-level exploit
Automatic key deletion (Double Ratchet)	Past message keys are deleted after decryption	Only protects messages already processed; current session keys remain in memory
Session timeout	Clears sensitive state after inactivity period	Does not protect against an adversary who gains access during an active session

Honest limitation. If an adversary compromises the client device while the application is active (or can extract keys from persistent storage), all messages currently stored on the device and all messages received during the compromise window are exposed. This is a fundamental limitation of any end-to-end encrypted system: the endpoints are, by definition, where plaintext exists. No protocol can protect data at the moment it is decrypted for display to the user.

Zentachain mitigates this through forward secrecy (limiting retrospective exposure), post-compromise security (limiting prospective exposure after re-keying), and client-side encryption of stored data (raising the bar for offline device analysis). But the honest assessment is that device compromise represents the most effective attack against any E2EE system, and Zentachain's protections in this category are limited, not comprehensive.

Protection level: Limited. Forward secrecy protects past deleted messages. Post-compromise security limits the duration of future exposure. Client-side encryption raises the difficulty of offline analysis. But active device compromise during a live session exposes current messages and key state. Users in high-risk environments should employ device-level protections (full-disk encryption, secure boot, hardware security modules) in addition to Zentalk's application-level measures.

Category 7: Quantum Adversary (Future Threat)

Definition. An adversary with access to a cryptographically relevant quantum computer (CRQC) -- a machine with sufficient logical qubits to execute Shor's algorithm against the key sizes used in Zentachain's cryptographic primitives. Current estimates suggest that breaking 256-bit elliptic curve cryptography (X25519, Ed25519) would require approximately 2,330 logical qubits. No such machine exists as of 2026, but the timeline for their development is measured in years to decades.

Adversary capabilities:

• Execute Shor's algorithm to solve the elliptic curve discrete logarithm problem (ECDLP) in polynomial time, breaking X25519 key agreement and Ed25519 signatures
• Execute Grover's algorithm to reduce the effective security of symmetric ciphers by half (AES-256 from 256-bit to 128-bit effective security; SHA-256 collision resistance from 128-bit to approximately 85-bit)
• Retroactively decrypt communications that were encrypted using only classical algorithms, if ciphertext was captured and stored ("harvest now, decrypt later")

Information that remains protected:

• Symmetric encryption. AES-256-GCM retains 128-bit security against Grover's algorithm. This exceeds any foreseeable computational capability, classical or quantum. Messages encrypted with AES-256 remain confidential against quantum adversaries.
• Post-quantum key agreement. Zentalk's hybrid key encapsulation (X25519 + ML-KEM-768, formerly CRYSTALS-Kyber-768) provides quantum resistance through the lattice-based Kyber component. Kyber-768's security is based on the Module Learning With Errors (MLWE) problem, for which no efficient quantum algorithm is known. Kyber-768 provides NIST Security Level 3, approximately 183-bit classical security (based on conservative core-SVP hardness estimates).
• Hash functions. SHA-256, used in address hashing and HKDF key derivation, retains approximately 85-bit collision resistance under Grover's algorithm -- adequate for all practical purposes.

Hybrid construction rationale:

The hybrid approach (X25519 + Kyber-768) is not a concession to uncertainty but a deliberate defense-in-depth strategy. The combined key is derived as:

sharedSecret = HKDF-SHA256(
  X25519_shared || Kyber768_shared,
  salt,
  info,
  32
)

The security of the combined scheme is at least as strong as the stronger of the two components. If X25519 is broken by a quantum computer, Kyber-768 provides security. If Kyber-768 is broken by a future classical or quantum algorithm (no such algorithm is currently known), X25519 provides security against classical adversaries. Both must be broken simultaneously to compromise the shared secret. This is a strict improvement over using either algorithm alone.

What remains vulnerable:

• Ed25519 signatures. Shor's algorithm can forge Ed25519 signatures, potentially enabling impersonation. Zentachain's migration plan includes transitioning to ML-DSA-65 (Dilithium3) for post-quantum signature security, deployed in a hybrid mode (Ed25519 + ML-DSA-65) analogous to the hybrid key encapsulation.
• Previously captured non-hybrid traffic. Any Zentalk traffic encrypted before the hybrid mode was deployed and captured by a "harvest now, decrypt later" adversary would be vulnerable to retrospective quantum decryption of the key agreement (X25519). However, the AES-256-GCM encrypted message content remains protected (128-bit quantum security), and the adversary would need the specific ephemeral keys from each session, which are deleted after use by the Double Ratchet.

Protection level: Full (with hybrid mode enabled). The hybrid X25519 + Kyber-768 construction ensures that Zentalk messages encrypted under the hybrid scheme are secure against both classical and quantum adversaries. AES-256-GCM message encryption provides 128-bit quantum security independently. The combination provides defense-in-depth: an adversary must break both a lattice-based problem and a symmetric cipher to compromise message confidentiality.

Security Guarantees

This section enumerates, in tabular form, the specific security properties that Zentachain guarantees and the mechanisms that enforce each guarantee. The distinction between mathematical and architectural guarantees is critical:

• A mathematical guarantee holds as long as the underlying cryptographic primitive is secure. It does not depend on honest behavior by any network participant, correct implementation of non-cryptographic components, or any assumption about the adversary's network position. Breaking it requires a cryptanalytic breakthrough.
• An architectural guarantee depends on the correct functioning of the system's structural design -- relay diversity, validator distribution, protocol compliance by a supermajority of nodes. It is robust but not unconditional: a sufficiently powerful adversary who controls enough of the infrastructure can degrade it.

Properties Guaranteed by Zentachain (In Scope)

Security Property	Guarantee Type	Mechanism	Adversary Defeated
Message confidentiality	Mathematical	AES-256-GCM encryption under the Double Ratchet; 256-bit keys derived per-message via HKDF-SHA256	All adversary categories (content remains encrypted even under full network compromise)
Message integrity	Mathematical	GCM authentication tags (128-bit); any modification to ciphertext is detected and rejected with overwhelming probability ($1 - 2^{-128}$)	Categories 1-5 (tampered messages are rejected)
Message authenticity	Mathematical	Ed25519 digital signatures on key bundles; GCM authentication on individual messages	Categories 1-5 (forged messages are rejected without the sender's private signing key)
Forward secrecy	Mathematical	Per-message symmetric key derivation via the Double Ratchet; immediate deletion of used keys; DH ratchet step generates new root keys	Categories 1-6 (compromise of current keys does not expose past messages whose keys have been deleted)
Post-compromise recovery	Mathematical	DH ratchet re-keying upon message exchange; new DH values generate cryptographically independent key chains	Category 6 (after both parties exchange new DH ratchet values, the compromised session state becomes insufficient to derive future keys)
Sender privacy	Architectural	Sealed sender protocol: ephemeral X25519 ECDH + AES-256-GCM encryption of sender address; relay infrastructure sees only the sealed blob	Categories 1-3 (relay nodes cannot identify the message sender)
Recipient unlinkability	Architectural	Stealth addresses: unique one-time address per message derived from recipient's stealth meta-address and sender's ephemeral key	Categories 1-4 (an observer cannot link multiple messages to the same recipient)
Network-level privacy	Architectural	Multi-hop relay routing (3 hops: Guard, Middle, Exit) with layered encryption; fixed-size 542-byte cells; timing obfuscation	Categories 1-3 (no single relay knows both sender and recipient); partial protection against Category 4
Quantum resistance (key agreement)	Mathematical	Hybrid X25519 + ML-KEM-768 (NIST FIPS 203); combined shared secret via HKDF	Category 7 (secure against both classical and quantum adversaries; requires breaking both ECDLP and MLWE simultaneously)
Quantum resistance (symmetric encryption)	Mathematical	AES-256-GCM retains 128-bit security under Grover's algorithm	Category 7 (128-bit quantum security exceeds any foreseeable computational capability)

Properties NOT Guaranteed by Zentachain (Out of Scope)

The following limitations are stated explicitly because omitting them would constitute a misleading security claim. Each limitation is either fundamental (inherent to any system of this type) or a deliberate design trade-off (where the alternative would impose unacceptable usability costs).

1. Full anonymity against a global passive adversary. Zentachain provides meaningful traffic analysis resistance through multi-hop routing, fixed-size cells, timing obfuscation, and cover traffic. It does not provide provable anonymity against an adversary who can observe all network traffic globally and perform long-term statistical analysis. Achieving this would require a full mix network with constant-rate cover traffic from all participants (as in Loopix or Nym), imposing multi-second latencies incompatible with real-time messaging. This is a deliberate design trade-off: practical usability over theoretical perfection.

2. Protection against a fully compromised client device. If an adversary gains root-level access to a user's device during an active Zentalk session, currently stored messages and session keys are exposed. Forward secrecy limits retrospective damage; post-compromise security limits prospective damage after re-keying. But the active compromise window is a fundamental vulnerability of any end-to-end encrypted system. The plaintext must exist somewhere for the user to read it; that somewhere is the device.

3. Protection against rubber-hose cryptanalysis (physical coercion). No cryptographic protocol can protect against an adversary who compels the user to reveal their keys through physical force, legal compulsion, or threat of harm. Zentachain does not implement deniable encryption or hidden volumes. The system cannot distinguish between voluntary and coerced access.

4. Protection against side-channel attacks on client hardware. Timing attacks, power analysis, electromagnetic emanation analysis, and cache-timing attacks on the client device are outside Zentachain's threat model. These attacks target the physical implementation of cryptographic operations, not the mathematical properties of the protocol. Mitigation is the responsibility of the client hardware, operating system, and browser.

5. Guaranteed message delivery. Zentachain provides best-effort message delivery with a 30-day offline queue TTL. Messages may be permanently lost if the recipient does not come online within the TTL window, if all validators holding queued messages fail simultaneously, or if a sustained denial-of-service attack prevents delivery. The system prioritizes privacy over guaranteed delivery: it will not fall back to less private delivery mechanisms to ensure a message arrives.

6. Protection against social engineering. If a user is deceived into communicating with an adversary, adding an adversary to a trusted group, or sharing their recovery phrase, no cryptographic mechanism can prevent the resulting information disclosure. Security is a property of the system's mathematical and architectural design, not of the user's judgment.

7. Protection against compromised random number generation. If the client device's cryptographically secure pseudorandom number generator (CSPRNG) is compromised -- through a backdoor in the operating system, a hardware flaw, or a supply-chain attack -- all cryptographic operations that depend on randomness (key generation, nonce generation, ephemeral key generation) are potentially compromised. Zentachain relies on the Web Crypto API's crypto.getRandomValues(), which in turn relies on the operating system's entropy source.

Formal Assumptions

The security guarantees enumerated above hold under the following assumptions. If any assumption is violated, the corresponding guarantees may be weakened or invalidated. Each assumption is stated precisely so that it can be independently evaluated.

Assumption 1: Cryptographic Primitive Security

The following cryptographic primitives are assumed to be secure at their stated security levels:

Primitive	Assumed Hard Problem	Security Level
AES-256-GCM	No efficient key recovery or distinguishing attack exists	256-bit classical, 128-bit quantum
X25519 (Curve25519 ECDH)	Elliptic Curve Discrete Logarithm Problem (ECDLP) is hard	128-bit classical
Ed25519 (EdDSA)	ECDLP on twisted Edwards curve is hard	128-bit classical
ML-KEM-768 (formerly CRYSTALS-Kyber-768)	Module Learning With Errors (MLWE) problem is hard	NIST Level 3 (~183-bit classical, quantum-resistant)
SHA-256	Preimage resistance: $O(2^{256})$; collision resistance: $O(2^{128})$	256-bit preimage, 128-bit collision
HKDF-SHA256	PRF security of HMAC-SHA256	256-bit

If a practical attack is discovered against any of these primitives -- for example, a polynomial-time algorithm for ECDLP, a practical AES key recovery attack, or an efficient quantum algorithm for MLWE -- the corresponding security guarantees are void. The hybrid construction (X25519 + Kyber-768) provides a hedge: both must be simultaneously broken to compromise key agreement.

Assumption 2: Secure Key Generation

The user's device is not compromised at the time of initial key generation (identity key, signed prekey, one-time prekeys). If the device is compromised during key generation, the adversary possesses the user's long-term identity key and can impersonate the user or decrypt all future communications. This assumption cannot be verified by the protocol and represents a trust boundary at the device level.

Assumption 3: Safety Number Verification

For protection against man-in-the-middle attacks on key exchange, it is assumed that the user verifies safety numbers for high-security contacts through an out-of-band channel (in-person QR code scan or voice comparison). If safety numbers are not verified, a MITM attack by an active network adversary (Category 5) may succeed undetected. The protocol is secure against MITM attacks only when safety numbers are verified; without verification, the protocol provides security against passive but not active adversaries.

Assumption 4: Honest Supermajority of Validators

At least two-thirds ($\geq 2n/3$) of validators are honest -- they follow the protocol correctly and do not collude with adversaries. This assumption is required for:

• Routing diversity: Multi-hop relay circuits constructed from a pool with an honest supermajority have a high probability of including at least one honest hop, preventing end-to-end traffic correlation.
• Data availability: Reed-Solomon erasure coding recovers stored data as long as a sufficient number of honest nodes serve their fragments.
• Economic security: Consensus mechanisms detect and slash misbehaving validators only if honest validators constitute a supermajority capable of reaching agreement.

If more than one-third of validators collude, routing privacy may be degraded, data availability may be compromised, and slashing mechanisms may be subverted. Content confidentiality (E2EE) remains unaffected regardless of the fraction of compromised validators.

Assumption 5: Secure Execution Environment

The user's operating system and browser provide a secure execution environment for the Zentalk Progressive Web Application. Specifically:

• Process isolation prevents other applications or browser tabs from reading Zentalk's memory
• IndexedDB storage is not accessible to other origins (same-origin policy is enforced)
• The Web Crypto API provides correct implementations of the cryptographic algorithms it exposes
• TLS certificate validation is performed correctly by the browser

If the operating system is compromised (rootkit, kernel exploit), if the browser has a vulnerability that breaks same-origin isolation, or if the Web Crypto API implementation contains a bug, application-level security guarantees may be bypassed regardless of the protocol's mathematical properties.

Assumption 6: Uncompromised Random Number Generation

The client device's CSPRNG (crypto.getRandomValues() in the Web Crypto API) produces output that is computationally indistinguishable from true randomness. All cryptographic operations in Zentalk -- key generation, nonce generation, ephemeral key pair creation, IV generation for sealed sender -- depend on this assumption. A compromised CSPRNG (e.g., one with a backdoor, insufficient entropy, or predictable state) would undermine all randomness-dependent security properties.

Composite Attack Scenarios

Real-world attacks rarely correspond to a single adversary category in isolation. The following scenarios illustrate how multiple attack vectors combine and how Zentachain's layered defenses respond.

Scenario A: Nation-State with Validator Collusion

An adversary operates several validator nodes (Category 3) while simultaneously conducting global passive traffic surveillance (Category 4). The adversary's controlled validators observe metadata on their fraction of network traffic, while global surveillance provides timing correlation across the entire network.

What is compromised: The adversary can probabilistically correlate sender and recipient IP addresses for circuits that pass through their controlled validators, with higher confidence than either capability alone provides. Communication patterns may be reconstructed over time through statistical analysis.

What remains protected: Message content (AES-256-GCM), sender identity within messages (sealed sender), and cryptographic key material. The adversary learns communication graph information but not communication content.

Mitigation: Users employ Tor to obscure IP addresses from both the controlled validators and the global surveillance infrastructure. Multi-hop circuit rotation limits the duration of any single correlation advantage.

Scenario B: Compromised Device Combined with Network Observation

An adversary installs malware on a user's device (Category 6) and simultaneously monitors network traffic (Category 4 or 5).

What is compromised: All messages on the compromised device, the user's identity keys, and network-level metadata. The adversary can both read messages and correlate them with network traffic patterns.

What remains protected: Messages on other users' devices. Forward secrecy of messages deleted before the compromise. Messages sent after the compromise is remediated and both parties complete a DH ratchet step (post-compromise security).

Mitigation: Device compromise is outside the protocol's protection scope. Users should employ device-level security measures. Zentalk's post-compromise security ensures that the impact is bounded in time once the device is secured and new DH ratchet values are exchanged.

Scenario C: Quantum Adversary with Harvested Ciphertext

An adversary has captured and stored encrypted Zentalk traffic (Category 7, "harvest now, decrypt later") and later acquires a cryptographically relevant quantum computer.

What is compromised (non-hybrid traffic): For traffic encrypted before hybrid mode deployment using only X25519, the adversary can break the ECDH key agreement and recover session keys, potentially decrypting stored ciphertext.

What remains protected (hybrid traffic): For traffic encrypted with the hybrid X25519 + Kyber-768 construction, the adversary must break both ECDLP (via Shor's algorithm) and MLWE (no known efficient quantum algorithm). AES-256-GCM retains 128-bit quantum security independently. The Double Ratchet's forward secrecy means that even recovering one session's keys does not expose other sessions.

Mitigation: Deploy hybrid mode as early as possible to minimize the window of non-hybrid traffic. Zentachain's hybrid implementation is available for all new sessions.

Summary

The threat model presented in this chapter establishes a precise security contract between Zentachain and its users. The contract is:

I. Message confidentiality, integrity, authenticity, forward secrecy, and post-compromise recovery are mathematical guarantees that hold against all adversary categories, including full network compromise and future quantum computers (with hybrid mode).

II. Sender privacy, recipient unlinkability, and network-level privacy are architectural guarantees effective against local and regional adversaries (Categories 1-3), with meaningful but not absolute protection against global passive adversaries (Category 4).

III. Device-level security is outside the protocol's scope. Defense-in-depth measures limit damage from device compromise but cannot prevent it.

IV. All guarantees depend on explicitly stated assumptions about cryptographic primitive security, random number generation, device integrity, safety number verification, honest validator supermajority, and secure execution environment.

This threat model is a living document. As the cryptographic landscape evolves -- new quantum algorithms, new lattice attacks, new side-channel techniques -- the adversary categories, protection assessments, and assumptions stated here will be revised. A threat model that does not evolve with the threat landscape is worse than no threat model at all, because it creates false confidence. Zentachain commits to maintaining this analysis as an accurate reflection of the system's actual security properties, including its limitations.