Privacy
Privacy and encryption
What mesh networks do and do not protect.
Updated 29 Oct 2026
Two separate questions
- Confidentiality. Can someone with a radio read the content of a message?
- Metadata. Can they see who is talking, when, and from where?
Most mesh systems address the first better than the second. Relays have to read enough of a packet to forward it, so some information is always exposed. The table summarises what the sources say.
| System | Content | Metadata and notes |
|---|---|---|
| Meshtastic | AES-CTR on channels; public-key encryption for direct messages | Packet header never encrypted; default channel key is public |
| MeshCore | Described as end-to-end encrypted; cipher not documented in sources we found | Not established |
| Reticulum | Encrypted by design (AES-256-CBC, X25519, Ed25519) | No source addresses on packets |
| AREDN | Amateur rules prohibit obscuring meaning | Traffic is meant to be open |
| Wi-Fi community meshes | Whatever your own traffic provides | Operators can see metadata (general networking knowledge) |
Meshtastic
Meshtastic channels use AES-CTR with 128- or 256-bit keys. The default primary channel uses the well-known public key AQ==, and the documentation is blunt about the consequence: "Anything sent on a channel with the default key can be read by anyone". If you want private group messages, create a channel with your own random key and share it only with the group.
Direct messages use public-key cryptography (an X25519 shared secret). Our sources did not confirm which release introduced that, so we do not give a version number.
The docs state that the packet header is never encrypted, because relays need it. They also state that Meshtastic's scheme is not equivalent to WPA3, TLS 1.3 or Signal, and list these limitations: no forward secrecy, no message integrity under plain AES-CTR (unless AES-CCM is used), public keys that are trusted on first hearing with no central authority, and X25519 not being quantum-resistant.
Practical consequence: assume anyone in range can see that your node exists and is talking, even if the content is protected. If you publish your position, anyone can see it; see Meshtastic and flash Meshtastic for setup, and check position-precision settings before you share.
MeshCore
MeshCore's website claims "end-to-end encrypted messaging", and the FAQ says each node has a public encryption key "which is also signed to prevent spoofing". We did not find the cipher suite in the FAQ or the packet-format document, so we do not state one. Read the current MeshCore documentation before relying on it for sensitive traffic. See MeshCore.
Reticulum
The Reticulum manual lists Ed25519 signatures, X25519 key exchange, "AES-256 in CBC mode with PKCS7 padding", HKDF and SHA-256/512. Links get forward secrecy from per-link ephemeral key exchange. Reticulum "does not include source addresses on any packets", and the initiator of a link can stay anonymous. This is a stronger starting point than the other LoRa systems on this page, but it describes the design in the version covered by the current manual; it is not an audit. See Reticulum and how mesh routing works for how routing works without source addresses.
AREDN and amateur radio
AREDN (Amateur Radio Emergency Data Network) runs on amateur-allocated spectrum. In the US, 47 CFR 97.113(a)(4) prohibits "messages encoded for the purpose of obscuring their meaning, except as otherwise provided herein". Applying that rule to AREDN is our inference from the regulation plus AREDN being an amateur-radio network; the AREDN pages we read do not state it themselves.
Community Wi-Fi meshes
A Wi-Fi mesh such as NYC Mesh carries ordinary internet traffic. NYC Mesh says it is "a neutral network and we do not monitor, collect, store or block any user data or content". That is a statement of policy by one network; it is not a technical guarantee, and other networks may differ. Whoever operates the routers along your path can in principle see unencrypted traffic and metadata such as destinations and timing (general networking knowledge, not sourced here). So:
- Use HTTPS for websites, and a VPN if you want to hide destinations from the mesh operators.
- Treat the mesh like any other ISP-level network for privacy purposes.
- See join a community Wi-Fi mesh for what joining involves.
Lessons from messaging apps
Offline mesh messaging apps have been broken before. The Bridgefy analysis (IACR ePrint 2021/214) describes tracking, no authenticity, weak confidentiality and fragility to crafted messages. A follow-up reported by Royal Holloway on 17 August 2021 found that Bridgefy's later Signal-based fixes were insufficient. See resilience in practice. The rule that follows is to ask a mesh project what its threat model is, rather than treating the word "encrypted" as the end of the discussion.
A short checklist
- Change the Meshtastic default key for any conversation you care about.
- Assume node names, positions and message timing are observable.
- Do not use a mesh for anything where being observed is dangerous unless you have read its security documentation.
- Keep expectations modest: what you can actually do describes what these networks are for.
Sources
- Meshtastic: encryption
- MeshCore
- MeshCore FAQ
- MeshCore packet format
- Reticulum manual: Understanding Reticulum
- Reticulum (GitHub README)
- 47 CFR 97.113 (US amateur service prohibited transmissions)
- AREDN documentation
- NYC Mesh
- IACR ePrint 2021/214 (analysis of Bridgefy)
- Royal Holloway: cryptographers urge caution over use of secure messaging app (17 August 2021)