Relay Network

Overview

The INCOG Relay Network is a decentralized, multi-hop encrypted routing infrastructure designed to eliminate network-layer metadata as a viable tracking and surveillance vector. The relay network operates as an independent layer from the browser, providing traffic routing obfuscation that protects against adversaries with visibility into the network layer — including ISPs, backbone operators, CDN providers, and government surveillance programs.

The relay network is not a VPN. A VPN shifts trust from an ISP to a VPN provider — the VPN provider gains complete visibility into unencrypted traffic and user behavior. The INCOG relay architecture is designed so that no single operator gains complete visibility, distributing trust across independent node operators through a cryptographic routing protocol.

Routing Architecture

Multi-Hop Design Rationale

The foundational design decision of the relay network is multi-hop routing: user traffic traverses multiple independent relay nodes before reaching its destination, with each node possessing only partial routing information.

The rationale for multi-hop design over single-hop proxying is straightforward: a single-hop proxy provides only server-side anonymity (the destination cannot identify the user) but not operator-side anonymity (the proxy operator has complete visibility into both origin and destination). Multi-hop routing, when implemented correctly, prevents any single node from constructing a complete picture of the routing path.

Specifically:

• The entry node knows the user's real IP and the next relay hop — but not the destination
• Intermediate nodes know only the previous and next hops — neither origin nor destination
• The exit node knows the destination and the previous hop — but not the origin IP
• No node in the path observes both the real origin IP and the final destination simultaneously

This property holds under the assumption that no adversary controls both the entry node and the exit node simultaneously. The protocol is designed to minimize this probability through relay selection policies.

Relay Path Construction

Relay paths are constructed by the INCOG Browser client using a distributed relay directory that maps available nodes by geographic region, capacity, uptime history, and operator identity. Path construction follows these constraints:

• Entry, intermediate, and exit nodes must be operated by independent entities (different registered operators)
• Nodes in the same geographic jurisdiction should not appear consecutively in the path, reducing the risk that a single surveillance authority can observe multiple hops
• Exit node selection accounts for destination geography to minimize unnecessary routing overhead
• Path diversity is maximized across sessions — the same relay path is not reused across browsing sessions

The relay directory is distributed and cryptographically signed. Nodes publish signed capability announcements, and the directory is updated on a continuous basis. Clients receive directory updates through a separate privacy-preserving channel to prevent directory queries from becoming a metadata leakage source.

Encryption Architecture

Layered Encryption Model

Traffic traversing the relay network is encrypted using a layered scheme in which each layer of encryption is removed by one hop in the path. This is analogous to the onion routing model, adapted for the INCOG protocol's specific trust assumptions and performance requirements.

The encryption model works as follows:

Client generates symmetric keys: K_entry, K_mid, K_exit

Payload is encrypted as:
  Encrypt(K_exit, payload)
  → Encrypt(K_mid, above)
  → Encrypt(K_entry, above)

Entry node decrypts outer layer using K_entry
  → Forwards doubly-encrypted payload to mid node

Mid node decrypts middle layer using K_mid
  → Forwards singly-encrypted payload to exit node

Exit node decrypts final layer using K_exit
  → Forwards plaintext payload to destination

Each symmetric key is established via an authenticated key exchange with the respective relay node, using the node's long-term public key (obtained from the relay directory) and an ephemeral client key pair. The key exchange is performed independently for each session, preventing key reuse and forward secrecy violations.

Forward Secrecy

All session keys are ephemeral. A compromise of a relay node's long-term private key does not retroactively expose the content of previously encrypted sessions, because session keys are derived from ephemeral ECDH exchanges and are not persisted by any party.

Traffic Analysis Resistance

Layered encryption addresses content confidentiality but not traffic analysis. An observer monitoring network links can still learn:

• Volume and timing of traffic between hops
• Packet sizes and inter-packet timing patterns
• Connection establishment events

The INCOG protocol addresses traffic analysis through:

Padding: Packets are padded to uniform sizes before relay transmission, preventing size-based traffic correlation across hops.

Timing normalization: A small, configurable amount of artificial latency jitter is introduced at each relay hop to frustrate timing correlation attacks. The latency budget is configurable by users according to their sensitivity-latency tradeoff preference.

Cover traffic: At sufficient network scale, the relay network supports cover traffic — dummy packets indistinguishable from real traffic — to reduce the signal-to-noise ratio for traffic analysis. Cover traffic is a network-scale property that becomes more effective as the number of simultaneous users increases.

Node Roles

The relay network distinguishes three node roles based on function:

Entry Nodes (Guard Nodes)

Entry nodes are the first point of contact between the user and the relay network. They observe the user's real IP address and are therefore the most sensitive nodes in the path from a user identity perspective.

Entry nodes are selected with additional scrutiny:

• Long-term uptime history is weighted heavily in entry node selection
• Entry nodes operated by known, established operators with track records are preferred
• Users may configure a persistent set of trusted entry nodes ("guard node pinning") to reduce the probability of being assigned a malicious entry node over time

The guard node concept reflects an insight from anonymity network research: frequent rotation of entry nodes increases the probability that a user will eventually connect through a malicious entry node. Persistent guard nodes — selected once and used for extended periods — reduce this probability at the cost of guard node operator visibility into user connection frequency.

Middle Relay Nodes

Middle nodes handle the intermediate hops of relay paths. They observe only adjacent hop identities and cannot determine whether they are the second or Nth hop in a path. Middle nodes handle the bulk of the network's routing capacity and are the most numerous node type.

Middle nodes have lower trust requirements than entry nodes and may be contributed by a broader set of operators, including home router deployments.

Exit Nodes

Exit nodes establish the final connection to the destination server. They observe the destination and the decrypted payload (for protocols that do not apply end-to-end encryption beyond the relay layer). Exit nodes do not observe the origin IP.

Exit nodes carry unique legal and operational considerations: from the perspective of the destination server, traffic appears to originate from the exit node's IP. Exit node operators should be aware of the traffic characteristics their node will handle and operate within applicable legal frameworks.

Relay Selection and Path Diversity

Selection Algorithm

The client-side relay selection algorithm balances several competing factors:

Privacy properties

• Operator diversity: nodes controlled by the same legal entity are not used in the same path
• Jurisdictional diversity: consecutive nodes in different legal jurisdictions
• Relay diversity: no relay path is reused across sessions

Performance properties

• Geographic efficiency: minimizes unnecessary geographic detours
• Capacity weighting: higher-capacity nodes are more likely to be selected
• Latency estimation: path selection incorporates estimated round-trip time

Resilience properties

• Failed or degraded nodes are excluded from selection until their health metrics recover
• The selection algorithm maintains a diverse pool of candidate nodes to prevent over-concentration

Path Failure Handling

Relay path construction can fail due to node unavailability, network partitions, or capacity exhaustion. The client handles path failures through:

• Automatic path reconstruction using the next candidate set from the relay directory
• Exponential backoff for repeated failures to the same node set
• Fallback to direct connection (with user notification) when relay path construction fails completely

Latency Characteristics

Multi-hop routing introduces latency relative to direct connections. The INCOG relay protocol is designed to minimize this overhead while maintaining privacy guarantees.

Typical latency overhead estimates:

These estimates are based on geographic proximity assumptions. Paths traversing multiple continents will exhibit higher latency. The relay directory provides latency estimates for path construction to allow the client to optimize within user-configurable constraints.

Performance vs. Privacy Tradeoffs

The protocol exposes several user-configurable parameters that allow explicit tradeoff between performance and privacy:

• Hop count: 2-hop paths reduce latency at the cost of weaker correlation resistance
• Timing jitter budget: reduces correlation attack viability at the cost of latency
• Path diversity aggressiveness: more aggressive path rotation reduces traffic analysis surface at the cost of connection establishment overhead

Advanced users can configure these parameters explicitly. Default settings are calibrated for privacy-first operation.