You have built a network that no corporation controls. You have mesh nodes on rooftops, LoRa radios in weatherproof enclosures, maybe a satellite backhaul link feeding your community’s traffic into the wider internet. You have decentralized applications running on local servers. You can communicate with your neighbors even when the commercial internet goes dark. You are free — right?
Not yet. Not even close.
Freedom without security is an illusion. An unencrypted mesh network is a party line where anyone with a radio can listen to every conversation. A mesh node running default firmware with default passwords is an open door that any script kiddie can walk through. A community network without authentication is a Sybil attack waiting to happen — a malicious actor spinning up fake nodes to intercept, modify, or disrupt traffic. And an alternative network whose operators do not understand operational security is a honeypot that draws attention from exactly the adversaries it was built to resist.
This chapter is about making your alternative network actually secure. Not “secure” in the marketing sense — a padlock icon on a login page, a privacy policy nobody reads. Secure in the engineering sense: encrypted at every layer, authenticated at every boundary, resistant to the specific attacks that alternative networks face, and operated by people who understand what they are protecting and from whom.
We will start with threat modeling — because you cannot defend against threats you have not identified. Then we will work through encryption fundamentals, authentication and identity, network-level security, anonymity and privacy tools, the unique security considerations of each alternative network type, physical security, operational security, and finally some Python tools you can use to implement cryptographic protections in your own applications.
This is the longest technical chapter in the book, and for good reason. Every other chapter assumes you will read this one. Security is not a feature you add at the end — it is a property of the entire system, and it must be designed in from the beginning.
The single most common security mistake in alternative networking — and in security generally — is building defenses without understanding the threats. People install VPNs without knowing what a VPN protects against (and what it does not). They enable encryption without considering key management. They worry about nation-state adversaries when their actual threat is a nosy neighbor with a software-defined radio.
Threat modeling is the disciplined practice of asking: what am I protecting, from whom, and what are they capable of? It is the foundation of every security decision you will make, and skipping it guarantees that you will either over-engineer protections you do not need (wasting resources and complexity) or under-engineer protections you desperately do (inviting catastrophe).
Alternative networks face every threat that conventional networks face, plus several that are unique to their architecture. Here are the major categories:
Eavesdropping. The most fundamental threat. Radio-based networks — Wi-Fi mesh, LoRa, packet radio — broadcast signals through the air. Anyone with an appropriate receiver can capture those signals. Unlike wired networks, where an attacker must physically tap a cable, wireless eavesdropping can be done passively, from a distance, with cheap equipment, and with no way for the network operator to detect it. A $25 RTL-SDR dongle and a laptop are sufficient to capture LoRa transmissions. A $50 Wi-Fi adapter in monitor mode can capture every frame on a mesh network. If your traffic is not encrypted, eavesdropping is trivial.
Traffic analysis. Even when traffic is encrypted, an observer can learn an enormous amount from metadata: who is communicating with whom, when, how often, and how much data is exchanged. Traffic analysis can reveal social networks, identify leaders and coordinators, and detect patterns of activity — all without breaking a single encryption key. Intelligence agencies have been conducting traffic analysis since World War I, and the techniques have only gotten more sophisticated. On a mesh network, where every node can observe the traffic it forwards, traffic analysis is a persistent and difficult-to-mitigate threat.
Node compromise. In a mesh network, nodes are distributed — often in physically accessible locations like rooftops, utility poles, or public buildings. An attacker who gains physical access to a node can extract encryption keys, install malware, modify routing tables, or replace the node entirely with a malicious one. Unlike a server locked in a data center with physical access controls, a mesh node on a rooftop is protected by little more than a weatherproof enclosure and the assumption that nobody will climb up and tamper with it.
Sybil attacks. Named after the pseudonymous case study of dissociative identity disorder, a Sybil attack occurs when a single adversary creates multiple fake identities to gain disproportionate influence over a network. In a mesh network that uses reputation-based routing or democratic governance, an attacker who controls a hundred fake nodes can outvote legitimate operators, manipulate routing decisions, or partition the network. Sybil attacks are particularly dangerous in decentralized networks because there is no central authority to verify that each identity corresponds to a unique, legitimate participant.
Jamming. Radio networks can be jammed — an attacker transmits noise on the same frequency, overwhelming legitimate signals. Jamming is the radio equivalent of a denial-of-service attack, and it is remarkably easy. A few watts of broadband noise can render a Wi-Fi mesh network inoperable within a radius of hundreds of meters. LoRa’s spread-spectrum modulation provides some jamming resistance, but a sufficiently powerful jammer can overcome it. Military and law enforcement agencies have purpose-built jamming equipment, but even a malfunctioning microwave oven can jam 2.4 GHz Wi-Fi.
Man-in-the-middle (MITM) attacks. An attacker positions themselves between two communicating parties, intercepting and potentially modifying traffic in both directions. Both parties believe they are communicating directly with each other, but the attacker sees everything. In a mesh network, a compromised intermediate node is a natural MITM position — it already forwards traffic between other nodes, so intercepting that traffic requires only a software modification, not a network intrusion.
Routing attacks. Mesh protocols rely on nodes honestly reporting link quality, topology, and routing information. A malicious node can advertise false routes to attract traffic (a blackhole attack), selectively drop packets (a grayhole attack), or inject false topology information to partition the network. The routing protocols discussed in Chapter 7 — BATMAN, Babel, OLSR — were designed primarily for functionality, not for adversarial environments, and most have limited defenses against routing manipulation.
Microsoft’s STRIDE framework provides a structured way to categorize threats. While it was designed for software threat modeling, it maps well to network security:
| Threat | Description | Alternative Network Example |
|---|---|---|
| Spoofing | Pretending to be someone else | Rogue node impersonating a legitimate mesh node |
| Tampering | Modifying data or systems | Altering routing tables on a compromised node |
| Repudiation | Denying an action occurred | Node operator denying they forwarded malicious traffic |
| Information Disclosure | Exposing data to unauthorized parties | Unencrypted mesh traffic captured by passive eavesdropper |
| Denial of Service | Making a system unavailable | Jamming the wireless frequency used by the mesh |
| Elevation of Privilege | Gaining unauthorized access | Exploiting a vulnerability in mesh node firmware to gain root |
Threat modeling is incomplete without understanding the capabilities of your adversaries. Different adversaries have different resources, different motivations, and different legal constraints:
The curious neighbor. Low capability, low motivation. They might scan your Wi-Fi network out of curiosity or boredom. Defense: basic encryption and access control. If your network requires a password and uses WPA3, the curious neighbor will move on.
The petty criminal. Moderate capability, financial motivation. They want to intercept credentials, hijack bandwidth, or use your network for illegal activity. Defense: encrypted traffic, authenticated nodes, monitoring for unusual activity.
The corporate adversary. Moderate to high capability, motivated by competitive intelligence or regulatory compliance. An ISP that views your community network as competition might attempt to disrupt it through legal, regulatory, or technical means. Defense: legal preparation, robust network architecture, documentation of compliance with radio regulations.
Law enforcement. High capability within legal constraints (which vary enormously by jurisdiction). Can compel disclosure of encryption keys in some countries, conduct surveillance with court orders, and deploy sophisticated interception equipment. Defense: end-to-end encryption (so there is nothing to disclose at the network level), minimal logging, legal counsel.
Intelligence agencies. Very high capability, few practical constraints. Can intercept signals at scale, compromise hardware supply chains, break or circumvent encryption implementations (though not, as far as publicly known, the underlying mathematics of strong encryption). Defense: defense in depth, open-source software (auditable for backdoors), hardware you physically control, operational security practices.
Not every alternative network needs to defend against intelligence agencies. A community mesh network providing neighborhood internet access has different security needs than a network supporting political dissidents in an authoritarian state. The key insight of threat modeling is matching your defenses to your actual threats — and being honest about both.
Encryption is the bedrock of network security. Without it, every other security measure is cosmetic — a lock on a glass door. With it, even an adversary who captures every single packet on your network learns nothing about the content. The mathematics of modern encryption are among the most thoroughly analyzed and battle-tested constructions in all of computer science, and you should use them everywhere, always, without exception.
Symmetric encryption uses the same key for encryption and decryption. If Alice and Bob both know the key K, Alice encrypts her message with K to produce ciphertext, sends the ciphertext to Bob, and Bob decrypts it with the same key K to recover the original message. The security of the system depends entirely on keeping K secret.
The dominant symmetric encryption algorithm today is AES (Advanced Encryption Standard), adopted by NIST in 2001 after a multi-year public competition. AES operates on 128-bit blocks and supports key sizes of 128, 192, or 256 bits. AES-256 — AES with a 256-bit key — is approved for classified information by the U.S. government and is the standard choice for serious security applications. There are no known practical attacks against AES-256; a brute-force search of the $2^{256}$ possible keys would require more energy than exists in the observable universe.
ChaCha20 is the other major symmetric cipher in widespread use, designed by Daniel J. Bernstein. ChaCha20 is a stream cipher (it encrypts data byte-by-byte rather than in fixed blocks), and it is often faster than AES on hardware that lacks dedicated AES acceleration — which includes many of the ARM processors and embedded systems used in mesh networking equipment. ChaCha20-Poly1305 (ChaCha20 for encryption, Poly1305 for authentication) is the cipher suite used by WireGuard, and it is a TLS cipher suite supported by all modern browsers.
For alternative networks, the choice between AES and ChaCha20 is usually determined by hardware. If your mesh nodes have AES-NI instruction support (most modern x86 processors do), AES-256-GCM is slightly faster. If they are running on ARM Cortex-A or MIPS processors without hardware AES support (common in consumer routers and embedded devices), ChaCha20-Poly1305 is typically faster and uses less power.
Symmetric encryption has a fundamental bootstrapping problem: how do Alice and Bob agree on the shared key K in the first place? If they can meet in person and exchange a key on a USB drive, the problem is solved — but that does not scale. If they try to send the key over the network, an eavesdropper captures it and the encryption is worthless.
Asymmetric encryption (also called public-key cryptography) solves this elegantly. Each participant has two mathematically related keys: a public key that can be shared openly and a private key that is kept secret. Data encrypted with the public key can only be decrypted with the corresponding private key, and vice versa. Alice can encrypt a message using Bob’s public key, and only Bob — who possesses the corresponding private key — can decrypt it. No shared secret is needed in advance.
RSA (Rivest-Shamir-Adleman, 1977) was the first widely used public-key cryptosystem and is still in use, though it is being gradually supplanted by elliptic curve cryptography. RSA’s security rests on the difficulty of factoring large numbers. RSA-2048 (using a 2048-bit key) is the minimum recommended key size today; RSA-4096 provides a larger security margin.
Elliptic Curve Cryptography (ECC) provides equivalent security to RSA with dramatically smaller keys. Curve25519, designed by Daniel J. Bernstein, is a widely used elliptic curve that provides approximately 128 bits of security with a 256-bit key — equivalent to RSA-3072 in security strength, but with keys that are 12 times smaller and operations that are significantly faster. Ed25519 is the signature scheme built on Curve25519, used for digital signatures in SSH, WireGuard, and many other protocols.
For alternative networks, ECC is almost always the right choice. Smaller keys mean less bandwidth consumed for key exchange, faster handshakes, and lower computational requirements — all critical on constrained mesh nodes.
The Diffie-Hellman key exchange protocol, published in 1976, allows two parties to establish a shared secret over an insecure channel without any prior shared secret. The protocol works by each party generating a private value, computing a public value from it, exchanging public values, and then independently computing the same shared secret from their own private value and the other party’s public value. An eavesdropper who sees both public values cannot compute the shared secret without solving the discrete logarithm problem, which is computationally infeasible for sufficiently large parameters.
ECDH (Elliptic Curve Diffie-Hellman) is Diffie-Hellman implemented using elliptic curves, typically Curve25519 (in which case it is called X25519). ECDH provides the same security as classical Diffie-Hellman with much smaller parameters and faster computation.
In practice, modern protocols use ephemeral Diffie-Hellman: fresh key pairs are generated for each session, and the resulting session keys are discarded after use. This provides forward secrecy — even if a long-term private key is later compromised, past session keys cannot be recovered, and previously recorded encrypted traffic remains secure.
Transport Layer Security (TLS) is the protocol that combines asymmetric key exchange, symmetric encryption, and digital certificates into a complete secure communication channel. When you visit an HTTPS website, TLS is what protects your traffic.
A TLS handshake proceeds roughly as follows:
ClientHello message listing supported cipher suitesServerHello, selecting a cipher suite, and sends its certificateTLS 1.3, finalized in 2018, streamlined the handshake to a single round trip, removed support for insecure cipher suites, and made forward secrecy mandatory. There is no reason to use anything older than TLS 1.3 in new deployments.
For alternative networks, TLS is essential for any service exposed on the network — web interfaces, API endpoints, MQTT brokers. Even on a “trusted” local network, TLS prevents a compromised node from eavesdropping on traffic between other nodes and the service.
End-to-end encryption (E2EE) ensures that only the communicating endpoints can read the messages — not the servers, not the network operators, not the mesh nodes forwarding the traffic. In an alternative network where traffic may traverse nodes operated by different individuals or organizations, E2EE is the only architecture that provides genuine confidentiality.
The Signal Protocol, used by Signal, WhatsApp, and Google Messages, is the gold standard for E2EE messaging. It combines the Double Ratchet Algorithm (providing forward secrecy and future secrecy for every message), X3DH (Extended Triple Diffie-Hellman) key agreement (allowing asynchronous key exchange — you can start an encrypted conversation with someone who is offline), and AES-256-CBC and HMAC-SHA256 for message encryption and authentication.
Megolm, used by the Matrix protocol, is designed for E2EE in group conversations and rooms. Where the Signal Protocol requires a separate ratchet for each pair of participants (making large groups expensive), Megolm uses a ratchet that can be shared with multiple recipients, making it efficient for the large rooms common in Matrix.
For alternative networks running Matrix (which we covered in Chapter 8), Megolm provides E2EE that protects messages even if the Matrix homeserver is compromised. This is particularly important when the homeserver is running on a mesh node that may be physically accessible to others.
Encryption protects confidentiality — it keeps secrets secret. But encryption alone does not tell you who you are communicating with. If an attacker performs a man-in-the-middle attack, intercepting your key exchange and substituting their own keys, you end up with a perfectly encrypted connection — to the attacker. Authentication is the mechanism that prevents this.
The simplest authentication method is a pre-shared key (PSK) — a secret known to all authorized participants before any communication begins. WPA2-Personal Wi-Fi networks use a PSK (the Wi-Fi password). WireGuard VPN tunnels use pre-shared keys as an additional layer of authentication. Meshtastic channels use a PSK for channel encryption.
PSKs are simple and effective for small, static groups. Their limitations become apparent as networks grow: distributing the key to new members requires a secure out-of-band channel (meeting in person, encrypted email), revoking access requires changing the key for everyone, and a compromised key compromises the entire network.
Public Key Infrastructure (PKI) is the system that binds public keys to identities. In the conventional internet’s PKI, Certificate Authorities (CAs) — trusted third parties like Let’s Encrypt, DigiCert, or GlobalSign — issue digital certificates that attest “this public key belongs to this domain name.” Your browser trusts a set of root CAs, and any certificate signed by a trusted CA is accepted.
This model has obvious problems for alternative networks. CAs are centralized authorities. Obtaining a certificate requires proving control of a domain name — which requires the DNS system, which requires the commercial internet. An isolated mesh network cannot use the CA-based PKI at all.
The Web of Trust model, used by PGP/GPG, takes a decentralized approach. Instead of trusting a central authority, each participant decides whom they trust. If Alice trusts Bob, and Bob has verified Carol’s key, Alice can choose to trust Carol’s key transitively. Trust is distributed, personal, and non-hierarchical.
In practice, the Web of Trust has struggled with usability. Key verification requires effort and understanding. Trust decisions are complex. Key revocation is unreliable. But the underlying concept — decentralized trust based on personal relationships — maps naturally to community networks where participants know each other.
Some mesh networking systems take a more elegant approach: your identity is your cryptographic key.
CJDNS, which we discussed in Chapter 7, generates an IPv6 address directly from the double-SHA-512 hash of each node’s public key. Your CJDNS address is fc00::/8 followed by a hash of your public key. This means:
Yggdrasil uses a similar approach, generating 0200::/7 addresses from Ed25519 public keys. The cryptographic identity is the node’s identity — there is nothing to forge, nothing to steal (unless you steal the private key), and nothing that depends on a centralized authority.
This cryptographic identity model is arguably the most natural fit for alternative networks: it requires no infrastructure, scales to any size, and provides both encryption and authentication by construction.
# Generate a Curve25519 key pair for mesh node identity
from cryptography.hazmat.primitives.asymmetric.x25519 import X25519PrivateKey
from cryptography.hazmat.primitives import serialization
import hashlib
private_key = X25519PrivateKey.generate()
public_key = private_key.public_key()
# Derive a node identifier from the public key hash
pub_bytes = public_key.public_bytes(
serialization.Encoding.Raw, serialization.PublicFormat.Raw
)
node_id = hashlib.sha256(pub_bytes).hexdigest()[:16]
print(f"Node identity: {node_id}")
print(f"Public key: {pub_bytes.hex()}")
Alternative networks are predominantly wireless, and wireless is inherently broadcast — every transmission can be received by any device within range. Network-level security provides the first line of defense, encrypting traffic at the link layer so that even passive eavesdroppers see only ciphertext.
If your mesh network uses Wi-Fi for its links (as many BATMAN-adv and 802.11s deployments do), WPA3 is the minimum acceptable security standard. WPA3, ratified in 2018, provides several critical improvements over WPA2:
Simultaneous Authentication of Equals (SAE) replaces WPA2’s PSK handshake with a zero-knowledge proof protocol based on Dragonfly key exchange. SAE is resistant to offline dictionary attacks — even if an attacker captures the handshake, they cannot test passwords offline the way they can with WPA2’s four-way handshake.
Forward secrecy ensures that compromising the Wi-Fi password does not allow decryption of previously captured traffic. Each session negotiates fresh keys.
Protected Management Frames (PMF) prevents deauthentication attacks — a common Wi-Fi attack where an adversary sends forged management frames to disconnect clients from the network.
For mesh backhaul links between nodes, WPA3-Personal (with a strong passphrase) is appropriate. For networks with centralized authentication infrastructure, WPA3-Enterprise (using RADIUS and EAP) provides per-user authentication and key management.
A Virtual Private Network (VPN) creates an encrypted tunnel between two points, protecting all traffic that passes through it from observation or modification. For alternative networks, VPNs serve two primary purposes: encrypting mesh backhaul links that traverse untrusted infrastructure, and connecting remote mesh segments over the internet.
WireGuard is the clear choice for new deployments. It is a modern VPN protocol designed by Jason Donenfeld and merged into the Linux kernel in 2020. WireGuard uses Curve25519 for key exchange, ChaCha20-Poly1305 for symmetric encryption, BLAKE2s for hashing, and SipHash for hashtable keys. Its entire codebase is roughly 4,000 lines of code — compared to hundreds of thousands for OpenVPN or IPsec — making it auditable, fast, and remarkably simple to configure.
A basic WireGuard configuration for connecting two mesh nodes:
# /etc/wireguard/wg0.conf on Node A
[Interface]
PrivateKey = <node_a_private_key>
Address = 10.0.0.1/24
ListenPort = 51820
[Peer]
PublicKey = <node_b_public_key>
AllowedIPs = 10.0.0.2/32, 192.168.2.0/24
Endpoint = nodeB.example.com:51820
PersistentKeepalive = 25
OpenVPN is the established alternative. It is slower than WireGuard and more complex to configure, but it runs in userspace (no kernel module needed), supports a wider range of cipher suites, and can operate over TCP (useful for traversing firewalls that block UDP). For legacy deployments or situations where WireGuard kernel support is unavailable, OpenVPN remains a solid choice.
IPsec is the oldest and most complex VPN technology. It is built into nearly every operating system and router, making it useful for interoperability with existing infrastructure. But its configuration complexity — involving security associations, Internet Key Exchange (IKE) negotiations, and dozens of interrelated settings — makes it a poor choice for new deployments where WireGuard is available.
Most mesh routing protocols were designed for cooperative environments and have limited built-in security. Securing them requires additional layers:
BATMAN-adv operates at Layer 2 and has no built-in encryption or authentication. Traffic forwarded by BATMAN-adv is visible to every node in the mesh. The standard approach is to layer encryption on top: WireGuard tunnels between nodes, WPA3 on the wireless links, and application-layer encryption (TLS, E2EE) for user traffic.
802.11s (the IEEE mesh networking standard) supports Simultaneous Authentication of Equals (SAE) — the same protocol used by WPA3 — for mesh peer authentication and link encryption. When properly configured, 802.11s encrypts all mesh traffic at the link layer.
CJDNS and Yggdrasil, as discussed above, encrypt all traffic by default using their cryptographic identity systems. If you are building a mesh network and security is a priority, these overlay networks provide encryption and authentication with zero additional configuration.
Every mesh node is a router, and every router needs a firewall. On Linux-based mesh nodes (which is most of them), nftables is the modern firewall framework, replacing the older iptables.
A minimal firewall configuration for a mesh node should:
#!/usr/sbin/nft -f
flush ruleset
table inet filter {
chain input {
type filter hook input priority 0; policy drop;
ct state established,related accept
iif "lo" accept
iif "bat0" tcp dport { 22, 443 } accept # SSH and HTTPS only
iif "bat0" icmp type echo-request accept
counter drop
}
chain forward {
type filter hook forward priority 0; policy accept;
ct state established,related accept
}
chain output {
type filter hook output priority 0; policy accept;
}
}
The principle is simple: a mesh node should forward traffic freely (that is its job) but should expose as few local services as possible to the mesh. Every open port is an attack surface.
Encryption protects the content of your communication. An eavesdropper cannot read your encrypted message. But encryption does nothing to hide the fact that you are communicating, with whom, when, how often, or how much data you are exchanging. This information — metadata — can be as revealing as the content itself.
A classic illustration: an intelligence analyst does not need to read the content of your calls to learn that you called a divorce lawyer, then a real estate agent, then a moving company, all in the same week. The metadata tells the story.
On alternative networks, metadata exposure is acute. In a mesh network, every intermediate node knows the source and destination of every packet it forwards. Even with encrypted payloads, the routing headers must be readable for the mesh to function. A single compromised node in a mesh path can conduct comprehensive traffic analysis on all traffic it forwards.
Metadata resistance — minimizing the information that metadata reveals — requires fundamentally different network architectures. This is where anonymity networks come in.
Tor (The Onion Router) is the most widely used anonymity network, with approximately 2 million daily users. Tor works by routing traffic through a series of three relays (called nodes or hops), each of which peels off one layer of encryption — hence the onion metaphor.
When you connect through Tor:
No single relay knows both the sender and the destination. The guard node knows who you are but not where your traffic is going. The exit node knows the destination but not who sent the traffic. The middle relay knows neither.
Tor Hidden Services (now called onion services) allow servers to be reached through Tor without revealing their IP address. An onion service generates an .onion address derived from its cryptographic key, and clients connect to it through a series of Tor relays. Neither the client nor the server learns the other’s IP address. For alternative networks, onion services allow you to host services — websites, messaging servers, file shares — that are accessible to Tor users without exposing your mesh node’s network address.
Running a Tor relay on your alternative network contributes to the global Tor network’s capacity and helps anonymize traffic for users worldwide. A non-exit relay (guard or middle) forwards encrypted traffic without any connection to the content of that traffic. An exit relay decrypts the final layer and connects to the destination, which carries legal risk since the traffic appears to originate from your exit relay’s IP address. For most alternative network operators, running a non-exit relay is the appropriate contribution.
# Check Tor circuit information using stem library
from stem import Signal
from stem.control import Controller
def get_tor_circuit_info(control_port=9051):
"""Display current Tor circuits and their relay paths."""
with Controller.from_port(port=control_port) as ctrl:
ctrl.authenticate()
for circ in ctrl.get_circuits():
if circ.status == "BUILT":
path = " → ".join(
f"{entry.nickname}({entry.fingerprint[:8]})"
for entry in circ.path
)
print(f"Circuit {circ.id}: {path}")
I2P (Invisible Internet Project) takes a different approach to anonymity. Where Tor is designed primarily to anonymize access to the regular internet (with onion services as an additional feature), I2P is designed primarily as a self-contained anonymous network — a darknet with its own internal services.
I2P uses garlic routing — a variation of onion routing where multiple messages are bundled together into a single encrypted “clove” and routed through the network as a unit. This makes traffic analysis harder because an observer cannot easily determine which messages in a bundle correspond to which communication sessions.
Key differences from Tor:
For alternative networks, I2P is particularly interesting because its architecture — a self-contained anonymous overlay network — maps naturally onto an isolated mesh network. You can run I2P entirely within your alternative network, providing anonymous communication between mesh participants without any connection to the commercial internet.
Mix networks (or mixnets) provide even stronger metadata resistance than onion routing by introducing deliberate delays and mixing at each hop. Instead of forwarding packets immediately, a mix node collects messages from many senders, reorders them, delays them by random amounts, and then forwards them in a different order. This breaks the timing correlation that is the primary weakness of low-latency anonymity networks like Tor.
Nym is a modern mixnet that adds cover traffic — fake messages that are indistinguishable from real messages to any observer. Even a global adversary who can observe every link in the network cannot distinguish real messages from cover traffic or correlate inputs to outputs at each mix node. Nym provides strong anonymity guarantees at the cost of higher latency — messages take seconds rather than the sub-second latency of Tor.
Katzenpost is a mixnet designed for asynchronous messaging, drawing on the academic research of the Loopix anonymity system. It provides strong metadata resistance for email-like communication, where latency in the range of seconds to minutes is acceptable.
For alternative networks supporting activists or at-risk populations, mixnets provide the strongest available metadata protection. The latency trade-off is significant, but for asynchronous communication — email, file transfer, dead-drop messaging — it is entirely acceptable.
| Tool | Content Protection | Metadata Resistance | Latency | Best For |
|---|---|---|---|---|
| TLS/HTTPS | ✅ Strong | ❌ None | Low | General web traffic |
| Tor | ✅ Strong | 🟡 Moderate | Medium | Anonymous browsing |
| I2P | ✅ Strong | 🟡 Moderate | Medium | Anonymous internal services |
| Nym Mixnet | ✅ Strong | ✅ Strong | High | High-risk async messaging |
| Signal (E2EE) | ✅ Strong | ❌ None (server sees metadata) | Low | Everyday secure messaging |
| Briar (P2P E2EE) | ✅ Strong | 🟡 Moderate | Medium | Mesh-native secure messaging |
Mesh networks present a unique security challenge: every node is both an endpoint and a router, and nodes are typically distributed across multiple physical locations with varying levels of physical security. A few principles apply across all mesh architectures:
Encrypt everything, always. There should be no unencrypted traffic on your mesh, period. Use WPA3 on wireless links, WireGuard between nodes, and TLS or E2EE at the application layer. Defense in depth means that compromising one layer does not expose everything.
Authenticate every node. Every node on the mesh should be identified by a cryptographic key pair. New nodes should be admitted only after their public key is verified by a trusted operator. Unauthenticated open mesh networks are invitations for Sybil attacks and rogue nodes.
Minimize the attack surface of each node. Mesh nodes should run the minimum software necessary for their routing function. Disable unused services. Apply security updates promptly. Use read-only filesystems where possible to prevent persistent compromise.
Monitor for anomalies. Implement monitoring that can detect unusual routing changes, unexpected traffic patterns, new nodes appearing without authorization, and nodes that drop an unusual percentage of traffic.
LoRa networks, and the Meshtastic firmware in particular, operate in an environment with severe constraints: low bandwidth (often under 1 kbps), limited processing power, and small packet sizes. These constraints limit the cryptographic options available.
Meshtastic uses AES-256 in CTR mode for channel encryption. All devices on a channel share the same encryption key, derived from the channel name and a pre-shared key. This means:
For most Meshtastic use cases — hiking groups, neighborhood communication, emergency coordination — this level of security is adequate. The primary threat is casual eavesdropping, and AES-256 provides strong protection against it.
For higher-security applications, Meshtastic supports direct messages with per-session encryption, and the community is working on improved key management. But the fundamental constraint remains: LoRa’s low bandwidth makes the handshakes required for perfect forward secrecy expensive in airtime.
Community networks — like Guifi.net, Freifunk, or NYC Mesh — face a governance challenge that purely technical solutions cannot address. When dozens or hundreds of independent operators contribute nodes to a shared network, security depends on the least careful operator.
Effective community network security requires:
Amateur (ham) radio occupies a unique position in alternative networking: in most jurisdictions, encryption is prohibited by regulation. The ITU Radio Regulations and most national regulations require amateur transmissions to be transmitted “in plain language” or using internationally recognized codes. The intent is that amateur radio is a shared, monitored public resource, and encrypted traffic would undermine that.
This creates a fundamental tension for ham radio data networks like Winlink, APRS, and packet radio. You cannot encrypt the over-the-air traffic. This means:
For alternative network builders, ham radio is a last-resort communication channel — invaluable when all other options are unavailable, but fundamentally unsuitable for private or sensitive communication. Use ham radio for coordination, welfare checks, and emergency traffic where the content is not sensitive. Use other channels — encrypted LoRa, mesh with VPN, internet where available — for private communication.
Cryptography protects data in transit and at rest. But if an adversary can walk up to your mesh node, pull out the SD card, read the encryption keys from flash memory, and install a modified firmware — your cryptography is irrelevant. Physical security is the often-neglected foundation on which all other security rests.
Mesh nodes, LoRa gateways, and wireless access points are frequently installed in physically exposed locations: rooftops, utility poles, park structures, community centers. Securing them requires:
Tamper-evident enclosures. Use enclosures with tamper-evident seals or screws that show visible damage if removed. This does not prevent tampering, but it allows you to detect it. Photograph your installations at each maintenance visit to establish a baseline.
Physical locks. Cable locks, padlocks on enclosures, and lockboxes provide deterrence against casual tampering. Against a determined adversary with bolt cutters, they buy you time and create noise — time and noise that may be enough to trigger detection.
Height and inaccessibility. Mounting equipment high on poles or structures makes casual access difficult. A node at 6 meters on a utility pole is vastly more secure than one at eye level on a fence post, simply because accessing it requires a ladder and deliberate effort.
Concealment. In some environments, the most effective physical security is invisibility. A mesh node in a nondescript weatherproof box, painted to match its mounting surface, draws no attention. An obviously technical device with antennas and blinking LEDs invites curiosity and theft.
For high-security deployments, passive physical security (locks and enclosures) can be supplemented with active tamper detection:
Tamper switches — microswitches or magnetic reed switches inside the enclosure that trigger when the enclosure is opened. Connected to the node’s GPIO pins, they can trigger an alert, log the event, or even wipe encryption keys from memory.
Secure boot ensures that only authenticated firmware can run on the node. If an attacker replaces the firmware with a modified version, the secure boot process detects the modification and refuses to boot. The Raspberry Pi 4 and later models, as well as many commercial routers, support secure boot chains.
Full-disk encryption protects data at rest on the node’s storage. Even if an attacker removes the storage device, they cannot read the contents without the encryption key. On Linux mesh nodes, LUKS (Linux Unified Key Setup) provides full-disk encryption with strong algorithms.
# Simple tamper detection using GPIO (Raspberry Pi)
import RPi.GPIO as GPIO
import time
import logging
TAMPER_PIN = 17 # GPIO pin connected to tamper switch
logging.basicConfig(filename="/var/log/tamper.log", level=logging.WARNING)
GPIO.setmode(GPIO.BCM)
GPIO.setup(TAMPER_PIN, GPIO.IN, pull_up_down=GPIO.PUD_UP)
def tamper_callback(channel):
logging.warning(f"TAMPER DETECTED at {time.strftime('%Y-%m-%d %H:%M:%S')}")
# Could also: send alert, wipe keys, shut down
GPIO.add_event_detect(TAMPER_PIN, GPIO.FALLING, callback=tamper_callback)
print("Monitoring tamper switch... Press Ctrl+C to exit.")
In this configuration, the tamper switch is normally closed (pulling the GPIO pin low). Opening the enclosure opens the switch, the pin goes high, and the falling-edge callback fires when the enclosure is closed again — or, with inverted logic, fires immediately upon opening. The callback can log the event, send an alert over the mesh, or take defensive action like zeroing encryption keys from memory.
Operational security is the human layer of security — the practices, habits, and discipline that prevent human error from undermining technical protections. The strongest encryption in the world is worthless if you discuss your encryption keys in an unencrypted group chat, leave your laptop unlocked in a café, or post a photo that reveals your mesh node’s location on social media.
For most alternative network operators, basic OpSec is sufficient: use strong passwords, keep systems updated, don’t share credentials unnecessarily. But for operators in high-risk environments — activists under authoritarian regimes, journalists protecting sources, communities targeted by state surveillance — OpSec must be rigorous, habitual, and paranoid.
Compartmentalization. Separate your identities and activities. The identity you use on the alternative network should not be linked to your legal identity, your social media accounts, or your phone number. Use separate devices for sensitive and non-sensitive activities. Do not cross-contaminate.
Minimize your footprint. Store the minimum data necessary. Delete messages after reading. Use ephemeral messaging where available. Do not keep logs of network activity unless absolutely necessary — and if you must log, encrypt the logs and rotate them aggressively.
Assume compromise. Design your practices so that the compromise of any single element — a device, a password, a team member — does not compromise everything. This means different passwords for every service, different encryption keys for different communication channels, and distributing knowledge so that no single person knows everything.
Verify out of band. When establishing encrypted communication, verify key fingerprints through a channel different from the one you are securing. Compare Signal safety numbers in person. Verify WireGuard public keys by reading them aloud over a phone call. Never trust a key that arrived through the same channel it is supposed to protect.
Practice and drill. OpSec is a skill, not a configuration. Practice your secure communication procedures regularly, including when you are not under threat. Run drills — what happens if a team member’s device is seized? What happens if a mesh node is compromised? Discovering that your procedures have gaps during an actual security incident is too late.
For day-to-day communication on your alternative network:
Your alternative network is accessed through devices — laptops, phones, Raspberry Pis. If the device is compromised, the network security is irrelevant.
The cryptography library is the standard Python library for cryptographic operations. It provides both high-level recipes (simple, hard to misuse) and low-level primitives (flexible, easy to misuse if you do not know what you are doing). Always prefer the high-level recipes unless you have a specific reason to use primitives.
# Encrypt and decrypt a message using AES-256-GCM
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os
def encrypt_message(key: bytes, plaintext: bytes) -> tuple[bytes, bytes]:
"""Encrypt a message with AES-256-GCM. Returns (nonce, ciphertext)."""
aesgcm = AESGCM(key)
nonce = os.urandom(12) # 96-bit nonce, MUST be unique per message
ciphertext = aesgcm.encrypt(nonce, plaintext, None)
return nonce, ciphertext
def decrypt_message(key: bytes, nonce: bytes, ciphertext: bytes) -> bytes:
"""Decrypt a message with AES-256-GCM."""
aesgcm = AESGCM(key)
return aesgcm.decrypt(nonce, ciphertext, None)
key = AESGCM.generate_key(bit_length=256)
nonce, ct = encrypt_message(key, b"Mesh node alpha: all clear")
print(f"Decrypted: {decrypt_message(key, nonce, ct).decode()}")
AES-GCM is an authenticated encryption scheme — it provides both confidentiality (the ciphertext reveals nothing about the plaintext) and integrity (any modification to the ciphertext is detected during decryption). The None parameter in the encrypt and decrypt calls is where you would pass additional authenticated data (AAD) — data that is authenticated but not encrypted, such as packet headers that must be readable by routers but must not be tampered with.
# X25519 key exchange between two mesh nodes
from cryptography.hazmat.primitives.asymmetric.x25519 import X25519PrivateKey
# Node A generates its key pair
node_a_private = X25519PrivateKey.generate()
node_a_public = node_a_private.public_key()
# Node B generates its key pair
node_b_private = X25519PrivateKey.generate()
node_b_public = node_b_private.public_key()
# Each node computes the shared secret using their private key
# and the other node's public key
shared_secret_a = node_a_private.exchange(node_b_public)
shared_secret_b = node_b_private.exchange(node_a_public)
# Both shared secrets are identical — this is the magic of DH
assert shared_secret_a == shared_secret_b
print(f"Shared secret established: {shared_secret_a[:16].hex()}...")
The shared secret produced by X25519 should not be used directly as an encryption key. It should be processed through a key derivation function (KDF) to produce keys of the appropriate length and with proper entropy distribution:
# Derive an encryption key from the shared secret
from cryptography.hazmat.primitives.kdf.hkdf import HKDF
from cryptography.hazmat.primitives import hashes
derived_key = HKDF(
algorithm=hashes.SHA256(),
length=32,
salt=None,
info=b"mesh-node-session-key",
).derive(shared_secret_a)
print(f"Derived AES-256 key: {derived_key.hex()}")
Combining everything — key exchange, key derivation, authenticated encryption — into a minimal secure messaging system suitable for a mesh network:
# Minimal secure messaging between mesh nodes
from cryptography.hazmat.primitives.asymmetric.x25519 import X25519PrivateKey
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
from cryptography.hazmat.primitives.kdf.hkdf import HKDF
from cryptography.hazmat.primitives import hashes, serialization
import os, json, base64
class SecureNode:
def __init__(self, name: str):
self.name = name
self.private_key = X25519PrivateKey.generate()
self.public_key = self.private_key.public_key()
self.sessions = {} # peer_name -> derived_key
def get_public_bytes(self) -> bytes:
return self.public_key.public_bytes(
serialization.Encoding.Raw,
serialization.PublicFormat.Raw,
)
def establish_session(self, peer_name, peer_pub_bytes):
from cryptography.hazmat.primitives.asymmetric.x25519 import (
X25519PublicKey,
)
peer_pub = X25519PublicKey.from_public_bytes(peer_pub_bytes)
shared = self.private_key.exchange(peer_pub)
self.sessions[peer_name] = HKDF(
algorithm=hashes.SHA256(), length=32,
salt=None, info=b"mesh-chat-v1",
).derive(shared)
def encrypt(self, peer_name: str, message: str) -> str:
key = self.sessions[peer_name]
nonce = os.urandom(12)
ct = AESGCM(key).encrypt(nonce, message.encode(), None)
payload = {"n": base64.b64encode(nonce).decode(),
"c": base64.b64encode(ct).decode()}
return json.dumps(payload)
def decrypt(self, peer_name: str, packet: str) -> str:
key = self.sessions[peer_name]
data = json.loads(packet)
nonce = base64.b64decode(data["n"])
ct = base64.b64decode(data["c"])
return AESGCM(key).decrypt(nonce, ct, None).decode()
# Demo: two nodes establish a session and exchange a message
alice = SecureNode("alice")
bob = SecureNode("bob")
alice.establish_session("bob", bob.get_public_bytes())
bob.establish_session("alice", alice.get_public_bytes())
encrypted = alice.encrypt("bob", "Mesh link stable. Signal -62 dBm.")
print(f"Encrypted packet: {encrypted[:60]}...")
print(f"Decrypted by Bob: {bob.decrypt('alice', encrypted)}")
This is a proof of concept — a production system would need message authentication codes on the framing, sequence numbers to prevent replay attacks, key rotation to provide forward secrecy, and error handling for every cryptographic operation. But it demonstrates the essential pattern: exchange public keys, derive a shared secret, use that secret for authenticated encryption. Every secure communication protocol, from TLS to Signal, follows this same fundamental structure.
Security and privacy on alternative networks are not optional features — they are architectural requirements. An alternative network without security is worse than the commercial internet, because it combines the worst of both worlds: no corporate resources for defense, and all the attack surface of a distributed system with physically accessible nodes.
The critical takeaways:
Threat model first. Understand your adversaries, their capabilities, and your specific risks before choosing defenses. A community mesh network sharing internet access needs different security than a network supporting political dissidents.
Encrypt everything, at every layer. WPA3 on wireless links. WireGuard between nodes. TLS for services. E2EE for messaging. Defense in depth means no single point of failure.
Cryptographic identity is the natural fit for decentralized networks. CJDNS and Yggdrasil demonstrate that identity, authentication, and encryption can be unified into a single elegant system.
Encryption protects content; anonymity protects metadata. If metadata exposure is a threat, you need Tor, I2P, or a mixnet — encryption alone is not sufficient.
Physical security and operational security are as important as cryptographic security. A stolen SD card with unencrypted keys defeats every protocol in this chapter.
Ham radio cannot be encrypted by regulation. Know the legal constraints of every technology you use.
Use established, audited cryptographic libraries — never roll your own crypto. The cryptography library in Python, libsodium in C, and the standard TLS libraries in every language exist precisely so that you do not have to implement AES or Curve25519 yourself.
The next chapter shifts from software to hardware — the physical components you need to build, power, and maintain the alternative network infrastructure that everything in this book depends upon.
| ← Previous: Satellite and Alternative Long-Range Links | Table of Contents | Next: Hardware Guide → |