MeshCore Security & Encryption
MeshCore encrypts all message payloads using AES-256-CTR. Understanding how this works helps you make informed decisions about what to transmit over the mesh and how to configure private channels.
What is encrypted
- All direct messages (DMs): Encrypted end-to-end with AES-256-CTR. Only the sender and recipient can decrypt them.
- Channel messages: Encrypted with the channel’s shared key. Anyone with the channel key can decrypt them.
- Routing credentials: The public keys used for path discovery are public by design — repeaters need them to route messages.
What is NOT encrypted (by design)
- Advertisements: Broadcast in cleartext so any node can discover repeaters. Contains node name, ID, and optionally position.
- Route requests/replies: Cleartext to enable routing by intermediate nodes that don’t have the message key.
- Node IDs in packet headers: Must be visible to routers for forwarding.
This means: if a node has GPS enabled and flood advertisements configured, its approximate location and identity are visible to anyone who can receive its radio transmissions. This is intentional — it’s what makes network maps and repeater discovery work. Configure accordingly if location privacy is important.
AES-256-CTR in practice
Counter (CTR) mode converts AES into a stream cipher. Each packet has a unique initialization vector (IV) derived from the sender’s identity, sequence number, and timestamp. Key properties:
- No padding required: Messages of any length are encrypted without adding bytes, keeping packets small.
- Parallelizable: Encryption and decryption can run in parallel, important on low-power MCUs.
- Nonce reuse is catastrophic: If the same IV is used twice with the same key, both messages can be decrypted by an attacker. MeshCore’s sequence number + timestamp IV generation is designed to prevent this — don’t modify IV generation in custom firmware.
Key management for direct messages
MeshCore generates a unique keypair for each node during initial setup. The private key never leaves the device. The public key is shared via advertisements and is used by other nodes to encrypt messages specifically for that device.
This is an asymmetric key exchange model for key agreement, with AES-256 for the actual message encryption. The details of the key agreement protocol are documented in the MeshCore protocol specification at github.com/meshcore-dev/MeshCore.
Channel security model
Channel messages use a symmetric key (the channel PSK) shared among all channel members. Security properties:
- Authentication: Any node with the PSK can both read and write to the channel. There is no per-member authentication within a channel — if you share the PSK with someone, they can impersonate any channel member.
- Forward secrecy: Not provided. If the PSK is compromised, past messages (if recorded by an attacker) can be decrypted retroactively.
- Key distribution: The PSK must be shared out-of-band (not over the mesh) using a separate secure channel.
Threat model: what MeshCore protects against
| Threat | Protected? | Notes |
|---|---|---|
| Passive eavesdropping of DMs | Yes | AES-256-CTR; attacker without private key cannot read DMs |
| Passive eavesdropping of channel messages | With PSK | Anyone with the PSK can read channel messages |
| Traffic analysis (who is talking to whom) | Partial | Node IDs are visible; message content is not |
| Location privacy | Configurable | Disable GPS or advertisements to prevent location tracking |
| Message injection into a channel | With PSK | Any node with PSK can inject messages |
| Relay node reading message content | Yes (DMs) | Relay nodes forward encrypted blobs; cannot read content |
| Room server reading DMs | Yes | Room server sees ciphertext only for DMs |
Security recommendations for sensitive use
- Use direct messages (DMs) rather than channel messages for sensitive communication — DMs are end-to-end encrypted with no shared key
- If location privacy matters: disable GPS and set advertisement hop count to 0 (local only)
- Distribute channel PSKs only to trusted participants and through secure out-of-band channels
- Rotate channel PSKs periodically if the membership of a private channel changes
- Do not transmit information that would cause serious harm if intercepted — LoRa radio is a wireless medium and physical-layer interception by a sufficiently determined attacker is always possible
Comparing to Meshtastic security
| MeshCore | Meshtastic | |
|---|---|---|
| DM encryption | AES-256-CTR, E2E | AES-256 (PKI-based in newer versions), E2E |
| Channel encryption | AES-256-CTR with PSK | AES-128-PSK |
| Key size | 256-bit | 128-bit |
| Default encryption | Always on | Default channel uses public key (visible to all) |
Both provide strong protection for practical threat models. The key difference is that MeshCore’s encryption is always active with no unencrypted fallback mode, while Meshtastic’s default channel uses a public key that provides confidentiality only against passive observers who don’t know the key (which is publicly documented).