You've set up your node, joined the default channel, and started sending messages. It feels private, there's no carrier, no server, no account tied to your name. But "off-grid" is not the same thing as "private," and Meshtastic's own documentation is upfront about where the line sits. Here's what's actually encrypted, what isn't, and what to change if privacy matters to you.
## Channels: encrypted, but only as private as the key
Every Meshtastic channel is encrypted with a pre-shared key (PSK) using AES256-CTR. That part is solid, AES256 is considered quantum-resistant, and nobody is brute-forcing it. The catch isn't the algorithm, it's the key.
Out of the box, every device joins the same default channel, LongFast, using the same publicly known key: `AQ==` (the Base64 form of a single byte, `0x01`). That key is hardcoded in the Meshtastic firmware source and is identical on every stock device sold anywhere in the world. It exists on purpose, for discovery and onboarding, so strangers' nodes can find and relay for each other. It was never meant to keep content private.
The result: messages on LongFast are technically encrypted, but practically public. Anyone with a Meshtastic radio in range, or anyone who's read the firmware source, which is all of us,can decrypt everything sent on it.
**The fix is simple:** create your own channel with a randomly generated AES256 key, give it a name only your group recognizes, and share the invite (QR code or key) out-of-band in person, over Signal, whatever isn't the mesh itself. In the official app this shows up as a green lock icon once it's a non-default key. That one change is the single biggest privacy upgrade available to any Meshtastic user.
## Direct messages: better than they used to be
Early Meshtastic DMs were just channel-encrypted messages addressed to a specific node, anyone with the channel PSK could technically read them. Firmware 2.5 fixed this with a real upgrade: direct messages and admin messages (the commands used to remotely configure a node) now use public key cryptography, an x25519 key exchange combined with AES-CCM, between any two nodes running 2.5.0 or newer.
This gives you three things the old system didn't: confidentiality, authentication (you know the message actually came from that node), and integrity (it wasn't altered in transit) but only once both nodes have exchanged public keys. If you or the person you're messaging are still on older firmware, or haven't exchanged keys yet, that guarantee doesn't apply.
One caveat worth knowing about: the key exchange itself trusts whichever public key a node number announces first, a model called Trust On First Use (TOFU). There's no central authority signing keys, so if an attacker impersonates a node number before the real owner does, later exchanges trust the wrong key. For most hobbyist and community use this is a minor theoretical risk; for anything sensitive, it's worth being aware of.
## What's never encrypted, no matter what you do
This is the part people miss. Every Meshtastic packet has a header that travels in cleartext by design, because relaying nodes need to read it to route the packet: sender ID, destination ID, packet ID, hop limit, and channel hash. Encryption protects the payload, not the metadata.
In practice that means anyone with a radio and a laptop can see who is talking to whom, how often, and roughly where (via signal strength and multiple listening points), even if they can't read a single word of the actual message. If your threat model includes someone caring about your movement patterns or contact network rather than your message content, encryption alone doesn't solve that, operational habits do (rotating node names, limiting how often you transmit, being deliberate about who's on your private channel).
## A quick reality check on quantum resistance
AES256, used for channel encryption, is generally considered safe against future quantum computers. The x25519 key exchange used for DM authentication is not, but that's true of nearly all public-key cryptography in use today, and current post-quantum schemes don't fit into a LoRa packet or run on the low-power microcontrollers Meshtastic devices use. It's a known, documented trade-off rather than an oversight, and not a reason to avoid the feature.
## Practical checklist
If you're setting up a node today, here's what actually moves the needle:
- Update to firmware 2.5 or later on every node you control, so DMs and admin commands get public-key protection instead of the old PSK-only scheme.
- Create a private channel with a randomly generated AES256 key for anything you don't want the general public reading. Keep LongFast for discovery only.
- Share channel keys out-of-band, never send a new channel's key over the mesh itself or over LongFast.
- Remember that headers are always visible. Don't assume "encrypted" means "untraceable."
- If you suspect a channel key has leaked, regenerate it and redistribute, there's no revocation mechanism, so a compromised key stays compromised until you change it.
## Where to start
Every Meshtastic-ready device we carry [WisMesh Pocket V2], [Heltec V3/V4] and the [RAKwireless WisBlock] range, ships capable of running the latest firmware, so the 2.5+ protections above are just a firmware update away if you haven't already. If you're building out a private mesh for a team, a family, or an event, take five minutes to set up your own channel key before you hand out the first device, it's the cheapest security upgrade you'll ever make.
