Threat Model What an adversary can and cannot do in Weave, per-primitive guarantees, and the cryptographic assumptions.
Weave's security posture in concrete terms: which attacks are addressed by the design, which are out of scope, and which cryptographic assumptions the system relies on.
Every byte that crosses the trust boundary is signed by an Ed25519 key and addressed by a BLAKE3 hash. The verifier on the receiving side rejects anything that fails either check.
The reference adversary has these capabilities:
Network . Can read, drop, reorder, and inject arbitrary packets between any two peers.Storage . Can read and modify any data on a compromised peer's disk.Compute . Polynomial-bounded; cannot solve discrete log or invert BLAKE3 within the security parameter.Identity . Does not have the private key of any honest participant.
The adversary cannot:
Forge an Ed25519 signature without the corresponding private key.
Find a preimage or second preimage for a BLAKE3 hash within the security parameter.
Compromise a peer's process memory at runtime (i.e. attacks are at network or disk boundaries).
Primitive Used for Assumption Ed25519 Block signatures, manifest signatures, identity proofs EdDSA security; 128-bit classical security BLAKE3 Content addressing (Strand blocks, Strand Blobs chunks, Weft chunks, Merkle roots) Collision and preimage resistance at 128-bit X25519 + Noise IK zer0-secret-stream handshake Standard Noise security model ChaCha20-Poly1305 zer0-secret-stream record encryption IND-CCA2
Warning
If any of these primitives break, the affected guarantees in the per-primitive table below also break. Treat the assumptions as the security floor of the system.
Property Holds against the adversary? Mechanism Forge a block under another writer's DID No Ed25519 signature on every block Reorder blocks within a strand No Sequence numbers + Merkle proofs Insert a block in the middle No Strand is append-only; any insert invalidates the Merkle root Drop a block silently No (writer can detect missing blocks via the Merkle bitfield) — Force a fork on a single writer No (a writer signs its own continuation) — Replay an old block No Sequence numbers are unique and increasing Read encrypted blocks without the key No with_encryption() enables per-block encryption
Property Holds? Mechanism Serve corrupted blob bytes No Chunk ids are BLAKE3 hashes; readers verify before delivering Substitute a different blob under a known id No Content addressing
Property Holds? Mechanism Forge an entry under another writer No Lens entries live inside a Strand Roll back a value to an old version Partial Snapshots and journal are signed; a peer can detect rollback by comparing log tips
Property Holds? Mechanism Forge file metadata No Operations are Strand blocks Inject file contents that do not match the metadata No Content hashes are part of the metadata block Bypass permissions on a local mount No (local) / Out of scope (remote) metadata-permissions.mdx describes the local enforcement
Property Holds? Mechanism Inject a tuple under another writer No All writes go through the writer's Strand Claim a tuple already taken by a different peer Race exists See Distributed Coordination Read a take you should not see Partial Strand is visible to anyone with replication access; encrypt at the Strand layer for confidentiality
Property Holds? Mechanism Forge a triple from another subject No (signing happens at the Strand layer) — Substitute the answer to a query No (queries are local) — Insert spurious triples through a malicious peer with replication access Yes, if the peer is trusted to write Apply policy at the writer DID layer
Property Holds? Mechanism Forge a vector entry No (Strand-signed) — Cause search to return incorrect neighbors Partial — HNSW recall is approximate; an adversary cannot make a search miss arbitrary entries, but can construct inputs that have many near-equal distances This is the inherent property of HNSW
Property Holds? Mechanism Serve corrupted chunk bytes No BLAKE3 id verified on fetch Substitute the manifest No Manifest is signed by producer DID Claim authorship of someone else's manifest No Signature is over the canonical manifest bytes (including the producer DID) Refuse to serve Yes (availability is not guaranteed)Sigil anchoring proves existence, not availability
Property Holds? Mechanism Tamper with values at rest in the DHT No for content-addressed records; Yes for mutable records Use content-addressing wherever possible Eclipse a peer (control all its neighbors) Partial — DHT design uses α = 3 parallel queries and a wide k-bucket A determined adversary with many peers can still eclipse a single victim Read DHT traffic Yes ; DHT records are not encrypted by defaultEncrypt sensitive content before storing
Property Holds? Mechanism Read plaintext of a session No Noise IK + ChaCha20-Poly1305 Replay a session frame No Per-frame nonce, monotonic counters MITM with a forged static key No Noise IK authenticates the responder's static key
Warning
The following are not defended by Weave's design. Mitigations are operational, deployment-level, or out-of-band.
Denial of service. A determined adversary can flood any peer's network. Mitigations are operational (rate limiting at the OS, swarm scoring) — Weave does not include a built-in DoS defense.Sybil-resistant peer admission. The DHT does not gate joiners. Treat peer ids as untrusted unless they are explicitly bound to a DID with a known root of trust.Time-bound revocation. Identity revocation is a chain concern (Sigil); Weave primitives accept whatever the identity adapter resolves.Confidentiality at rest on a compromised peer. If an attacker has full read access to a peer's disk, encrypted strands are still confidential, but any plaintext-stored data is exposed. The recommended deployment posture:
Enable Strand::with_encryption() for confidential strands.
Sign every cross-peer message at the application layer; do not rely solely on the transport.
Use Weft + Sigil anchoring for content that must be provably published.
Treat DHT records as public unless they are individually encrypted before storage.
Wrap the DHT in weave-dht-daemon so an external process boundary contains adapter bugs.