A LoRa mesh node is a small board with a microcontroller, a sub-gigahertz radio and an antenna, usually running the open-source Meshtastic firmware and paired to a phone over Bluetooth. You type into an app, the phone hands the message to the radio, the radio transmits it, and every other node in range rebroadcasts it until it reaches the far end. There is no base station and no operator. Hikers use it above the treeline, sailors use it out of VHF range, and it turns up wherever people expect the cellular network to be unavailable or monitored.
That last group is the one this article is written for, because the security model is genuinely useful and genuinely narrower than the way it gets described in a group chat.
Three things called LoRa, and they are not the same
The name gets applied to three separate layers, and conflating them is where most of the confusion starts.
LoRa is a physical-layer modulation scheme owned by Semtech, using chirp spread spectrum in the unlicensed sub-gigahertz bands (868 MHz across most of Europe, 915 MHz in North America, 433 MHz in some regions). It defines how bits become radio waves. It says nothing about encryption, addressing or routing.
LoRaWAN is a separate specification from the LoRa Alliance that runs on top of that modulation. It is a star topology: sensors talk to gateways, gateways talk to a network server over the internet. It has its own AES-128 session key scheme, and it is aimed at fleets of industrial sensors, not at people messaging each other.
Meshtastic is the firmware most people mean. It ignores LoRaWAN entirely and builds a flood-routed mesh directly on the LoRa radio, with its own packet format, its own encryption and no gateway requirement. When someone says "encrypted mesh radio," this is almost always the thing.
The channel key model
A Meshtastic channel is a name and a pre-shared key. Everyone who wants to talk to each other configures the same key, usually by scanning a QR code or sharing a URL that contains it. The message payload is encrypted with AES in counter mode under that key.
This is a group password, and it has the properties a group password has. Every member can read every message on the channel, including messages between two other members. There is no per-member key, so removing someone means generating a new key and redistributing it out of band to everyone else. A member who leaves on bad terms keeps a working key until you do that.
The part that surprises people: the default channel that a freshly flashed node joins uses a documented default key. It is not a secret and was never intended to be one, because the default channel exists so that strangers can find each other and so that the mesh has traffic to route. Anyone within radio range running stock firmware can read it. If you have not deliberately created a channel with your own key, your messages are being broadcast to everyone in range in a form they can decode by default.
Create a new channel with a randomly generated key and share it out of band. Leaving traffic on the default channel is closer to a public radio net than to encrypted messaging, and the interface does not distinguish between the two.
What travels in the clear
Encryption covers the payload. The packet header has to stay readable, because every node in the mesh needs to make routing decisions about packets it cannot decrypt: whether it has seen this packet before, whether the hop limit is exhausted, whether to rebroadcast.
| Field | Readable without the channel key? |
|---|---|
| Message text | No |
| Sender node ID | Yes |
| Destination node ID, or the broadcast address | Yes |
| Packet ID and hop limit | Yes |
| Which channel the packet belongs to | A hash of the channel name, which is enough to group traffic |
| That a transmission happened at all, and from what direction | Yes, at the radio layer |
A passive listener with a matching radio and no key still learns the social graph: which node IDs exist, which ones talk to which, how often, and in what pattern around an event. That is metadata, and on a mesh it is unusually rich, because the flood-routing design means you receive traffic that was never addressed to you.
Node identity is also stickier than it looks. Nodes broadcast a short profile so the mesh can show human-readable names in the app: a long name, a short name, the hardware model. That profile is sent on the channel, so anyone with the channel key gets a labelled map of the participants. If any of those names is a real name or a callsign, the pseudonymous node ID stops doing any work.
Direct messages and the newer key exchange
More recent firmware added per-node key pairs on Curve25519, so that a direct message between two nodes can be encrypted to the recipient's public key rather than to the shared channel key. Public keys are distributed in the same node-info broadcasts. This is a real improvement, and it means a channel member can no longer read every private exchange happening on their channel.
Two limits are worth stating plainly. First, key distribution happens over the air with no verification step by default, so the trust model is trust on first use: whatever key arrived first is the key you use, and a node that answered before the real one wins. Second, this covers direct messages. Channel traffic, position broadcasts and telemetry still use the shared key.
No forward secrecy, and what a seized node gives up
The channel key does not rotate on its own. It is the same key this week as last week, which means a listener who records ciphertext now and obtains the key later can decrypt everything they recorded. Protocols with forward secrecy derive a fresh key per message precisely so that a later key compromise does not unlock the archive. A shared static PSK gives up that property by construction.
This matters most in the scenario people actually buy these radios for. A node is a small unencrypted computer with the channel key in flash and, usually, a message history. Anyone who takes possession of one node has the key for the whole channel, has the recorded history on that device, and can decrypt any traffic that was captured while the key was in use. Nothing about the design limits the damage to one participant.
A shared key means the security of every conversation on the channel equals the security of the least protected device holding it.
The radio layer is a separate threat model
Everything above concerns the packet format. Underneath it is a radio transmitting at a known frequency, and radio has properties that no amount of payload encryption changes.
- Transmitters can be located. Radio direction finding is old, cheap and effective. A device that periodically announces itself is a device that can be walked up to, whatever its packets contain.
- Reception is undetectable. Someone recording your mesh leaves no trace in it. You cannot enumerate your listeners the way you can enumerate members of a group chat.
- Range depends on terrain, not on the advertised figure. Line of sight from high ground can reach far past what the app's list of known nodes suggests.
- Transmitting has legal shape. The unlicensed bands come with duty cycle and power limits that vary by region, and a device configured for one region's band plan may be non-compliant in another.
Compare this with a mesh built on phone radios, such as Briar over Bluetooth and Wi-Fi, where the range is short enough that proximity is roughly what it appears to be. A LoRa mesh trades exactly that property for distance.
What it is genuinely good at
None of this makes LoRa mesh a bad tool. It is the right tool for a specific job: keeping a known group in contact when there is no infrastructure to use, or when using the infrastructure would itself be the disclosure. It has no account, no phone number, no carrier record and no server that can be subpoenaed, and those are real properties that a messaging app on a cellular network cannot offer at any price.
The accurate summary is that it protects message contents from a listener without the key, and protects almost nothing else. Treat it as a group radio net with encrypted contents, set your own channel key, assume the pattern of transmissions is visible, and do not put anything on it that would be damaging if a single node were picked up.
Where there is a network and the question is what the server can see, the design work goes somewhere else: per-member keys, membership changes that rekey the group, and forward secrecy that survives a device seizure. Haven uses MLS for those properties. Both models get called encrypted, and the word does not distinguish them.