Warpnet Security Model

Warpnet is designed as a secure, decentralized, serverless communication system. Its security architecture is layered and cryptographically grounded, with no need for third-party trust or certification authorities.

This page describes what is actually implemented today, including the parts that are deliberately weak and the parts that are not finished yet. Where a mechanism has a known limitation, it is stated here rather than omitted.

1. Storage Layer Security

WarpNet uses BadgerDB as its embedded storage engine. All user data is stored locally and encrypted at rest.

Encrypted Local Database

When the node is started, it requires the user to log in with a username and password. These credentials are used to:

1. Unlock and decrypt the BadgerDB database

2. Generate an in-memory session token used to pair additional devices

3. Derive the node's long-term private key

Access to the database is impossible without the correct username/password pair. There is no backdoor, recovery key, or fallback mode. If the user forgets their password, the database is unrecoverable.

Password Policy

Passwords must be 8 to 32 characters long and contain at least one uppercase letter, one lowercase letter, one digit and one special character. The password is never written to disk and never logged.

Credential-Derived Secrets

Database encryption key

dbKey = sha256(username + "@" + password)

This 32-byte key is handed to BadgerDB, which encrypts data files with AES-256 in CTR mode. A wrong password surfaces as a key mismatch and the database refuses to open.

Known limitation, stated plainly: this key is a single SHA-256 pass. There is no salt and no password-stretching KDF (no Argon2, scrypt or PBKDF2) on this path. An attacker who obtains the database files can mount an offline dictionary attack at full hashing speed. Hardening this derivation is a planned change. Until then, treat OS-level full-disk encryption as a required companion, not an optional extra.

Session token

tokenSeed = username + "@" + password + "@" + network + "@" + randomByte + "@" + currentTime token = base64(sha256(tokenSeed))

This token lives only in memory and authenticates the pairing of additional devices — mobile phones acting as lightweight alias nodes. It is not used as a per-request credential for the desktop frontend; see section 7 for how the local dashboard is protected.

Deterministic private key

pkSeed = base64(sha256(username + "@" + password + "@" + network + repeat("@", password.length))) privateKey = GenerateKeyFromSeed(pkSeed) // Ed25519

GenerateKeyFromSeed appends the hash-algorithm and key-type identifiers to the seed, hashes it once more with SHA-256, and uses the result as the Ed25519 seed.

This ensures the private key is:

• Not stored on disk

• Reproducible from credentials alone

• Consistent between sessions

• Distinct per network — the same credentials produce different identities on warpnet and testnet

Note that the node identity is therefore derived, not randomly generated. The strength of your node identity is exactly the strength of your password.

File-level Protection

BadgerDB files are only accessible to the user that runs the node. Use file-system encryption and OS-level sandboxing in addition to the internal crypto.

Process Hardening

At startup the node unsets LD_PRELOAD, disables core dumps (PR_SET_DUMPABLE = 0), and aborts if a debugger such as gdb or lldb is attached. Derived keys are zeroed in memory immediately after use to reduce the value of a RAM snapshot.

2. Peer-to-Peer Encryption with Noise + PSK

All WarpNet nodes communicate using libp2p, which provides an encrypted transport layer using the Noise Protocol Framework. WarpNet uses the XX handshake pattern, combined with a Pre-Shared Key (PSK) to gate network access.

Key features:

• Mutual authentication without certificates

• Access control via PSK — nodes with a mismatched PSK cannot complete a handshake

• No certificate authorities are involved in establishing peer identity

• Every node uses an Ed25519 keypair; the Peer ID is the public key, so a peer's identity cannot be spoofed

• End-to-end encryption between nodes using Noise, with no central trust anchors

• Stream multiplexing over yamux, with a 15-second keep-alive and a 30-second connection write timeout

3. DPI-Resistant Camouflage Transport

WarpNet does not speak plain libp2p over the wire. The default transport is a custom camouflage transport that defeats Deep Packet Inspection through two complementary techniques.

TLS camouflage. A real TLS tunnel is established using uTLS with a genuine browser fingerprint (Chrome by default; others are selectable) on the client side, and standard TLS with a plausible two-certificate chain on the server side. The Noise handshake and all application data travel inside this tunnel, so to a DPI middlebox the connection looks like ordinary HTTPS browser traffic. The default SNI is a common, unremarkable hostname, and the TLS handshake timeout is 10 seconds.

TCP fragmentation. The initial bytes of the TLS ClientHello are split into very small TCP segments — covering the whole ClientHello — with optional random inter-segment delays. Stateful DPI that only inspects the first segment cannot match known signatures.

Active probing defenses. SNI/ALPN consistency validation, a plausible certificate chain, and configurable handshake and accept timeouts.

Note the layering carefully: TLS here is a disguise, not the trust anchor. Peer identity and confidentiality still come from Noise XX inside the tunnel. A forged or self-signed camouflage certificate grants an attacker nothing.

4. Pre-Shared Key (PSK)

The PSK acts as a gatekeeping mechanism — nodes with mismatched PSKs cannot connect or handshake. It separates one WarpNet network from another; it is not a secret that protects you from a determined adversary.

PSK derivation

seed = networkName + majorVersion + anchoredConstant psk = sha256(seed)

Input components:

• networkName — warpnet or testnet. The alias mainnet is normalised to warpnet so both spellings produce the same PSK.

• majorVersion — the major component of the semantic version

• anchoredConstant — a fixed constant defined in the source, iterated through SHA-256 ten times

What this buys you — and what it does not

It does buy: clean separation between networks, and a hard break between major protocol versions, so incompatible generations of nodes cannot half-connect and corrupt each other's state.

It does not buy secrecy. All three inputs are public. WarpNet is AGPL-licensed and the constant is in the repository, so anyone can compute the PSK for any network in milliseconds. Treat the PSK as a network identifier with a handshake gate, not as an access credential. Nothing in WarpNet's confidentiality guarantees rests on the PSK being unknown — that job belongs to Noise XX and to the camouflage tunnel.

It does not verify code integrity. An earlier version of this page stated that a hash of the codebase feeds into the PSK. That is not the case: the derivation takes only the three inputs listed above. A modified build derives the same PSK and joins the network normally. A codebase-hashing routine exists in the source but is not currently wired into any runtime check. Binary attestation is an open problem, and we would rather say so than imply a protection we do not have.

Version granularity is coarse. Only the major version participates. WarpNet is currently in the 0.x series, which means every 0.x release shares one PSK. The version gate becomes meaningful at 1.0.

PSK rotation is not yet implemented.

5. Per-Network Isolation

The network name is not cosmetic. It is mixed into:

• the PSK

• the node's private key seed — so the same credentials yield a different identity on each network

• the session token seed

• the DHT protocol prefix (/<network>)

• the rendezvous namespace (warpnet/rendezvous/<network>)

• the local database path

A node on testnet and a node on warpnet share no identity, no PSK and no discovery space.

6. Message-Level Authentication

Transport encryption protects the pipe. WarpNet additionally authenticates every message that travels through it.

Signed envelopes. Every inbound protocol message must carry an Ed25519 signature. The verifying public key is recovered from the sender's Peer ID, so a peer cannot claim to be someone else — the identity and the key are the same object. Unsigned, malformed or badly-signed messages are rejected and the stream is closed. The signature covers the message body and its timestamp, so neither can be altered independently.

Replay protection. A signed message whose timestamp drifts more than 5 minutes from local time — in either direction, so clock skew is tolerated symmetrically — is rejected as stale or replayed. Loopback self-streams are exempt, since they never leave the machine.

Payload size cap. Reads from a stream are bounded at 50 MiB by a limiting reader. A peer that exceeds the cap has its stream reset rather than gracefully closed. Uploaded images are subject to the same ceiling.

Idempotency. POST-style routes are guarded by an idempotency cache keyed on (protocol, peer, message id), with a 10-minute TTL. Duplicate requests — double-clicks, client retries, network re-sends — return the original response instead of re-executing the side effect. Concurrent requests sharing a key collapse so the handler runs exactly once. The cache is bounded at 1024 entries and 64 KiB per entry, and error responses are never cached.

Moderator verdict signatures. Moderation verdicts reach a node over pubsub, so the transport connection cannot vouch for their origin. Each verdict carries the issuing moderator's Peer ID and an Ed25519 signature that must verify against the key recovered from that Peer ID. Without this check, anyone subscribed to the topic could forge a verdict and shadow-ban arbitrary users. The signed bytes are assembled with explicit length prefixes rather than re-marshalled JSON, so signer and verifier agree byte-for-byte even across versions that add unrelated fields.

7. Local Dashboard Protection

The desktop dashboard talks to the node over a local WebSocket endpoint. It is protected by:

• Same-origin enforcement on the WebSocket upgrade — a request whose Origin host does not match the Host it connects to is rejected, so a malicious web page cannot open a socket to your node. Requests with no Origin (non-browser clients, health probes) are allowed.

• Bounded concurrency — at most 32 in-flight dispatches per connection, so one slow client cannot exhaust memory.

• A 10-second read-header timeout.

• Optional AES-256-GCM frame encryption using a key derived from a password in the node configuration. For the headless remote build this password is mandatory.

Bind the dashboard to localhost. It is not designed to be exposed to a network.

8. Abuse and DoS Resistance

• Peer discovery rate limiting — a leaky-bucket limiter admits at most 32 newly discovered peers, draining at 2 per 10 seconds. The discovery queue additionally sheds old entries with jitter on overflow. Note this limiter is global, not per-peer or per-protocol.

• Dial backoff — WarpNet's own exponential backoff: 100 ms doubling to a 5-minute ceiling, with up to 100 ms of jitter, a maximum of 5 attempts, and history expiring after 10 minutes.

• Resource management — libp2p's ResourceManager with autoscaled default limits caps streams, buffers and memory per peer. The connection manager keeps a low-water mark of 20 and a high-water mark of 50 connections with a 1-hour grace period. These values are currently compile-time constants; exposing them as user settings is planned.

• Blocklist — blocked peers are skipped during discovery and never dialled. A user-initiated social block is permanent until manually lifted.

• Escalating bans (implemented, not yet wired) — a four-level ladder exists in the storage layer: 1 hour, then 24 hours, then 7 days, then permanent, with the level persisted across incidents. It is fully implemented and tested but is not yet invoked by any runtime policy. Today only manual permanent blocks take effect.

• Mobile clients run in a restricted profile: client-only mode with no listen addresses, and a resource limiter scaled to 16 MB and 128 file descriptors.

Known gap: no connection gater. libp2p supports a ConnectionGater interface for rejecting inbound connections by IP or Peer ID before they are established. WarpNet does not currently register one. The blocklist is consulted on the outbound path during discovery only, which means a blocked peer can still open an inbound connection. Closing this gap is a known task.

9. NAT Traversal and Relays

WarpNet enables AutoNAT v2, Circuit Relay v2 (both client and service), DCUtR hole punching, NAT port mapping, and autorelay with static relays and a 5-minute backoff.

Be aware of the metadata consequence: when your traffic is relayed, the relay operator can observe that you connected to a given peer and when, even though it cannot read the content — that stays sealed inside Noise, inside the camouflage tunnel.

10. Media Metadata: Weak by Design

This section describes a mechanism that is intentionally breakable. Please read it before publishing images.

When you upload an image or a video, WarpNet embeds encrypted metadata into the file. That metadata includes node information, user information, and the hardware addresses of the machine's network interfaces.

The encryption is Argon2id followed by AES-256-GCM, but the password is drawn from a deliberately small space of roughly 1.1 × 10¹¹ values (~2^36.7), used once, and discarded immediately. It is never stored and never logged. The salt and nonce are public and travel with the file. Files uploaded together share one metadata blob, so per-file passwords would not raise the attacker's cost.

The intended property is that recovery is possible but expensive. With Argon2id at 64 MiB of memory per guess, a single attempt costs roughly 19–22 ms, which puts an exhaustive search on the order of days for a thousand-core cluster and years for a laptop. Treat those numbers as an order of magnitude, not a promise.

The purpose is attribution: the metadata acts as proof of ownership and responsibility. The consequence is that an adversary with serious computational resources — a state actor, a large data centre — can recover the node, user and hardware addresses behind any image you publish. An ordinary user cannot. If that trade-off is unacceptable for your threat model, do not publish images through WarpNet.

11. Summary of Known Weaknesses

We would rather list these than have you discover them:

1. The database encryption key is an unsalted single-pass SHA-256 of the credentials, with no KDF stretching. Use full-disk encryption.

2. The PSK is publicly derivable and is not a secret. It gates networks, not adversaries.

3. Codebase integrity is not verified at runtime; a modified build joins the network normally.

4. Only the major version participates in the PSK, and WarpNet is still in 0.x.

5. No ConnectionGater is registered, so the blocklist does not filter inbound connections.

6. The escalating ban ladder is implemented but not yet triggered by any policy.

7. Rate limiting is global at the discovery layer; there is no per-peer or per-protocol stream limiting.

8. Media metadata, including hardware addresses, is recoverable by a well-resourced adversary by design.

9. PSK rotation is not implemented.

10. Resource and connection limits are compile-time constants, not user settings.