Here's a scenario worth sitting with for a moment. Two hikers, miles from a trailhead, pull out their Meshtastic devices and start exchanging messages. Nearby, someone else has a Meshtastic node running — same radio frequency, same region settings, same mesh. Can they read those messages? The answer depends entirely on something most new users gloss over during setup: channels.

Channels are the layer where Meshtastic gets genuinely interesting, and where a lot of first-time users make a mistake that quietly undermines everything they thought was private.

The first thing to understand is that channels in Meshtastic are not radio frequencies. That distinction trips up almost everyone coming from walkie-talkie or ham radio backgrounds, where "channel" means a specific frequency you dial to. In Meshtastic, all nodes in a given region broadcast on the same LoRa frequency band — there's no tuning to a different channel in the radio sense. A channel in Meshtastic is a logical overlay, a software-defined grouping that sits on top of the shared radio medium. Think of it less like a radio dial and more like a shared document that only people with the right password can read, even though the document is passing in plain sight through a public space.

The official Meshtastic documentation on channel configuration^[1] describes this directly: every packet transmitted over the mesh is visible to every node within radio range, but the channel system determines who can make sense of what they receive. The channel name and its cryptographic key together define membership. If your key matches the sender's key, you can decrypt the message. If it doesn't, the packet is noise.

Stay with that for one more step, because it changes how you think about the whole system. The mesh itself is completely agnostic about who's in which channel. Nodes relay packets they can't decrypt. A router node — one of the fixed devices set up to extend range — will happily forward a message it cannot read, because its job is to carry packets, not to gate access. The privacy mechanism is entirely cryptographic, not topological. There's no server deciding who's in the club. The radio transmits, nodes relay, and only the right key unlocks the content.

That cryptographic mechanism is AES-256-CTR — Advanced Encryption Standard with a 256-bit key running in counter mode. Counter mode is a design choice worth understanding briefly. In counter mode, the encryption algorithm generates a stream of pseudo-random data by repeatedly encrypting an incrementing counter value, then XORs that stream against the plaintext. The practical advantage is speed and simplicity in embedded systems: it doesn't require padding, handles variable-length messages cleanly, and is well-suited to the constrained processors inside LoRa devices. AES-256 is the same standard used to protect classified government communications in the United States — at the key length used here, a brute-force attack is not a realistic threat. As the Meshtastic documentation on device encryption^[2] notes, the system uses a 256-bit key derived from the channel settings, providing strong symmetric encryption for all channel traffic.

Symmetric encryption means everyone in the channel shares the same key — the same secret is used to encrypt and to decrypt. That's the source of the most consequential problem in Meshtastic's default configuration, and it's worth spending real time here because it catches a huge number of users off guard.

When a device ships and you first bring it online, it joins a channel called LongFast with a default pre-shared key. That key is publicly documented. It appears in the Meshtastic source code, in the documentation, and in countless tutorials and forum posts. The Meshtastic documentation on default configuration^[1] is explicit that the default channel is intentionally set up this way — it's meant to allow new nodes to join the global mesh and communicate with strangers out of the box, which is a genuinely useful feature for discovery and community building. But it means that any message sent on the default channel with the default key is readable by any Meshtastic device anywhere using that same default setup. The encryption is technically present and functioning. But it provides zero confidentiality, because the key is universally known.

This is the default channel key problem, and it's a category error that trips up new users constantly. The error is assuming that because the app shows messages are "encrypted," those messages are private. They are encrypted in the sense that the cryptographic operation is being performed. They are not private in any meaningful sense, because the key is public knowledge. It's roughly equivalent to locking a diary with a combination that comes printed on the lock.

The practical implication: anything you send on the default LongFast channel should be treated as a public broadcast. Names, locations, meeting points, emergency plans — if that information matters, it should not go over the default channel. This isn't a criticism of the design; the default channel exists precisely so that strangers can discover and communicate with each other, and it serves that purpose well. The mistake is assuming it provides confidentiality that it was never designed to provide.

Here's where the system becomes genuinely capable of real privacy: custom channels. Creating a private channel in Meshtastic means defining a channel name and either letting the app generate a cryptographically random 256-bit key, or importing a key shared through another means. According to the Meshtastic documentation on channel configuration^[1], a channel is defined by the combination of its name, its key, and the modem preset — the radio settings that govern how packets are transmitted. Two devices are in the same channel if and only if all three of those elements match.

The workflow for sharing a private channel is designed for offline bootstrapping, which is fitting for a system built around scenarios where internet connectivity may not exist. The channel configuration can be shared as a QR code — you set up the channel on your device, generate the QR code in the app, and the person next to you scans it. Done. Their device is now configured with the same channel name, key, and modem preset as yours. From that point forward, messages between you over that channel are encrypted with a key that exists nowhere public, known only to the people who scanned that QR code. The Meshtastic channel sharing documentation^[1] describes this as the intended mechanism for distributing channel credentials to a trusted group before heading into the field.

The channel system supports multiple channels simultaneously on a single device — up to eight in the current implementation. One channel slot is designated the primary channel, which governs the node's LoRa radio settings and handles position broadcasts. The remaining slots are secondary channels, which can carry messages but inherit the radio configuration from the primary. This matters operationally: if your group wants to run a private channel alongside the public default, you can have both active. Your device participates in both, relaying packets for both, and presents messages from each in separate conversations in the app.

There's a subtlety here worth flagging. Position packets — the GPS coordinates your device broadcasts — go out on the primary channel. If your primary channel is the default LongFast with the default key, your position is visible to anyone on the mesh running default settings. If you want your location to be private, your primary channel needs to be your private channel, not the default. That's a configuration detail that doesn't get enough attention in introductory guides, but it matters significantly in scenarios where location privacy is important.

Now, channel-based PSK encryption handles group messages well. But what about a direct message between two specific people — something that only one recipient should be able to read, even within a shared channel? That's where Meshtastic's implementation of public key cryptography comes in, and it represents a meaningful evolution in how the system handles private communication.

Public key cryptography operates on a fundamentally different principle than symmetric encryption. Instead of a shared secret, each device generates a pair of mathematically linked keys: a public key that can be freely shared with anyone, and a private key that never leaves the device. A message encrypted with someone's public key can only be decrypted by their corresponding private key. No shared secret needs to be exchanged ahead of time, which solves a long-standing problem: how do you communicate privately with someone you haven't coordinated with in advance?

The Meshtastic documentation on PKI and direct messages^[2] describes how the system uses a variant of this approach for direct messaging. When your device discovers another node on the mesh, it can learn that node's public key. Direct messages can then be encrypted in a way that only the intended recipient — the holder of the matching private key — can decrypt. This is true even for nodes that are relaying the packet to its destination. Every router that forwards that direct message sees an encrypted payload it cannot read, because it doesn't hold the recipient's private key.

This is a meaningful security upgrade over channel-based PSK for one-to-one communication. The catch is practical: the two nodes need to have encountered each other on the mesh, or exchanged public key information somehow, before the PKI-encrypted direct message is possible. In a well-established local mesh where nodes have been operating for a while, this happens organically. In a first-contact scenario between strangers, there may be a bootstrapping moment where the initial exchange happens over channel PSK before PKI direct messages become available.

Worth knowing, too, is that Meshtastic's security model has limits it's honest about. The Meshtastic encryption overview^[2] notes that the system is designed to provide reasonable privacy against passive eavesdroppers and casual interception — not to provide the kind of hardened security guarantees that would satisfy a threat model involving sophisticated adversaries with dedicated radio hardware and cryptanalysis capability. For most use cases — hiking groups, neighborhood networks, event coordination, emergency preparedness communities — the security model is more than adequate. For someone operating in a context where adversarial interception is a serious concern, understanding those limits matters.

There's also the practical security hygiene of key distribution to consider. A private channel is only as secure as the process used to share its key. If the QR code gets photographed by the wrong person, or if a device with the channel configured is captured or stolen, the channel's confidentiality is compromised. The cryptography is sound; the human process around key management is where real-world security breaks down, just as it does with every encryption system ever deployed.

The through-line of everything in this section is that Meshtastic's channel system gives you real tools for real privacy — but only if you use them intentionally. The default setup is designed for openness and discoverability, not confidentiality. A custom channel with a randomly generated key and QR-code-based distribution gives your group strong encryption for group messages. Public key cryptography for direct messages adds another layer for one-to-one communication. And understanding that position packets follow the primary channel is the detail that keeps your GPS coordinates inside your trusted group rather than broadcasting to the wider mesh.

Setting up that private channel takes about two minutes in the app. The hard part was understanding why it matters — and now that groundwork is laid. The next question is how the nodes carrying those encrypted packets decide whether to forward them at all, which comes down to the roles each device plays in the mesh.

Sources cited

1. The official Meshtastic documentation on channel configuration meshtastic.org ↩
2. As the Meshtastic documentation on device encryption meshtastic.org ↩