Security and Privacy Model

GuardianMesh uses end-to-end encryption, signed identity, and multiple layers of traffic analysis protection. No custom cryptography — every primitive is peer-reviewed and well-studied. No relay, guardian, or intermediary can read message content.

End-to-End Encryption

All messages are end-to-end encrypted before leaving the sender's device.

X3DH Key Agreement

Sessions are established via the Extended Triple Diffie-Hellman protocol. Four Diffie-Hellman operations (IK↔SPK, EK↔IK, EK↔SPK, EK↔OPK) derive a shared secret via HKDF-SHA256. Signed pre-key signatures prevent man-in-the-middle attacks. No trusted third party is involved.

Double Ratchet

Per-message forward secrecy via a symmetric chain key ratchet: each message uses a unique key that cannot be reconstructed from current state. A DH ratchet rotates keys every round-trip, providing post-compromise recovery — even if an attacker compromises current keys, future messages become secure again after one exchange. Out-of-order message handling supports up to 256 skipped keys per chain.

MLS Group Messaging (RFC 9420)

Group conversations use Messaging Layer Security with TreeKEM for O(log n) key updates. Epoch-based transitions provide forward secrecy for groups. Credentials are Ed25519-signed and validated on every KeyPackage processing event.

Identity and Trust Model

Signed Identity

Every node is identified by an Ed25519 keypair. The identity hash is derived as SHA-256(Ed25519_publicKey), producing a 32-byte (256-bit) identifier with approximately 2¹²⁸ birthday resistance. All messages are signed and verified end-to-end.

Key Rotation

Keys can be rotated with cryptographic rotation certificates: the old key signs a certificate binding the new public key and a timestamp. Verification confirms the old key authorized the transition. Revocation certificates are supported for compromised keys via a RevocationRegistry.

Web-of-Trust

A decentralized trust system with 6 levels replaces centralized certificate authorities:

• Unknown (0): No prior contact
• FirstContact (1): First interaction, unverified
• UnverifiedKnown (2): Repeated contact, not yet verified
• Extended (3): Verified by a trusted peer
• Indirect (4): Verified through a chain of endorsements
• Direct (5): Personally verified (e.g., QR code exchange)

Endorsements are Ed25519-signed and walk the trust chain to resolve the effective trust level for any peer.

Username Credentials

Human-readable usernames are bound to Ed25519 keys via signed credential claims. Verification requires only the claim and the public key — no username authority needed.

Privacy and Anti-Surveillance

Onion Routing

Multi-hop layered encryption where each relay peels one layer and forwards to the next. Constant-size padding (512 B to 64 KB) prevents traffic analysis based on message size. No single relay in the circuit knows both the sender and recipient. Circuit states are tracked through building, open, closed, and failed phases.

Cover Traffic

Optional constant-rate dummy packet generation: 512-byte packets every 2 seconds so observers cannot distinguish real communication from background noise. Battery-aware (pauses below 30%, resumes above 50%). Cellular-aware mode disables cover traffic on metered connections. Real messages transparently replace cover packets mid-stream.

Message Mixing

Guardian relays can apply mixing to defeat timing correlation:

• Random delay injection: 100–2000 ms uniform distribution
• Batch shuffling: Fisher-Yates randomization of queued messages
• Dummy message padding: indistinguishable from real traffic
• Constant-rate output: 2 messages per second regardless of input rate

Traffic Obfuscation

• obfs4: Packet scrambling with randomized sizes and timing jitter. No detectable protocol fingerprint on the wire.
• meek: CDN tunneling makes traffic look like normal HTTPS to cloud providers (Amazon, Google).
• Domain fronting: TLS SNI shows a legitimate front domain while the actual destination is different.

Transport Security

Noise XX (WebSocket Sessions)

All WebSocket relay sessions use the Noise XX handshake pattern (Noise_XX_25519_AESGCM_SHA256). Three-message mutual authentication: both sides learn each other's static key. Ephemeral keys provide forward secrecy. Static keys are encrypted after the first DH exchange, hiding identities from passive observers. Optional prologue binding for channel and version verification.

BLE Identity Verification

BLE mesh connections authenticate via Ed25519 challenge-response. A random challenge is issued with a 30-second expiry to prevent replay attacks. Connections are rate-limited to 20 sends per peer per second and 10 mesh forwards per second. Maximum 7 concurrent BLE connections with stale connection reaping.

Replay Protection

Per-message-type replay windows with nonce deduplication. Time-window sizes are calibrated per message type (HandshakeInit: 30s, PeerAnnounce: 60s, Ping: 10s). Memory-bounded at 10,000 tracked sources for PeerAnnounce messages.

What Guardians Verify

• Auth challenge/response for signaling sessions
• Signed guardian announce payloads (Ed25519 public key + SHA-256 identity hash binding)
• Bundle metadata validity (ID, destination hash format, TTL, hops, payload size)
• Bundle signature verification via the sender's Ed25519 public key
• Replay protection via bloom-filter deduplication (512-byte filters, 4 hash functions)

What Is Exposed Publicly

• Region-level node visibility by default
• Node fingerprints, liveness, and capability metadata
• No precise location unless explicitly opted in by host operator

Abuse Controls

• Actor-segmented rate limits and pending quotas (max 500 queued messages per peer)
• Store pressure handling with deterministic rejection reasons
• Deduplication and anti-loop constraints for federation forwarding (LRU bloom filter cache)
• BLE mesh: bounded forwarding (3 hops default), rate limiting (10 forwards/sec), deduplication cache
• Reconnection throttling: exponential backoff (100 ms base, 30 s cap, max 5 retries)
• Per-bundle-store limits: 10 MB total and 100 bundles max per peer

Cryptographic Primitives

No custom cryptography. Every primitive is peer-reviewed:

• Ed25519 — Signing for identity binding, message authentication, and credential claims (via @noble/curves)
• X25519 — Diffie-Hellman for authenticated key agreement (via @noble/curves)
• AES-256-GCM — Authenticated symmetric encryption with 12-byte random nonce per message (via @noble/ciphers)
• SHA-256 — Hashing for identity derivation, key derivation, and bundle integrity (via @noble/hashes)
• HKDF-SHA256 — Key derivation for X3DH, Double Ratchet chain keys, and credit account IDs
• PBKDF2-SHA256 — Master key derivation with 310,000 iterations (NIST 2024 recommendation)
• CSPRNG — All security-critical randomness via crypto.getRandomValues() with rejection sampling for uniform integer distribution

Secure Storage

• Secure deletion with overwrite (not just unlink) via SecurePartitionManager
• Hardware keystore integration: Android Keystore and iOS Secure Enclave for AES-256 key storage (Ed25519 operations remain in software)
• Configurable access levels: WhenUnlocked, WhenUnlockedThisDeviceOnly, WithAuthentication
• Message expiry manager for time-based automatic cleanup
• Distributed storage with Reed-Solomon forward error correction for redundancy