Switch Language

index

Explanation

Meshtastic provides AES256-CTR encryption for the payload of each packet when sending via LoRa, with a different key for each channel. The packet header is always sent unencrypted, which allows nodes to relay packets they can't decrypt as well. One can disable this by setting a different rebroadcast mode.

By default, you have one primary channel, which is encrypted with a simple known key ("AQ=="), so to use proper encryption, you must change this key first, or create a new channel and share it with the ones you want to communicate with. However, without a channel using the default key, communication with devices still using it will not be possible.

Direct messages to a specific node are now encrypted using Public Key Cryptography (PKC). Each node is equipped with a unique public/private key pair, and direct messages are encrypted with the recipient's public key. This ensures that only the recipient can decrypt the message using their private key. Additionally, messages are signed with the sender's private key, allowing the recipient to verify the sender's identity and ensuring the message's integrity.

All periodic broadcasts (position, telemetry, traceroutes, etc.) the device sends out itself are sent over the primary channel and thus encrypted with that key.

The device will decrypt the payload before sending it to a client app via BLE, serial, Wi-Fi/Ethernet. For MQTT, you can specify whether you want to send an encrypted or unencrypted payload.

Is it as secure as Wi-Fi WPA3, HTTPS TLS1.3, or Signal?

No.

WPA3, TLS1.3, Signal, and Meshtastic can all use AES256. Yet AES is one of the many cogs required in a modern encryption system. Below are the main features "missing" in Meshtastic.

Perfect-Forward-Secrecy

Perfect-Forward-Secrecy, also known as PFS, means previous communications and more generally anything passively captured cannot be decrypted even when the key is compromised.

This means Meshtastic is vulnerable to « Harvest now, Decrypt later » attacks. This attack itself is not enough to decrypt messages; it relies on another failure leaking the channel key, such as:

Other protocols, such as misconfigured TLS1.2, are far more impacted by Harvest now, Decrypt later attacks because their keys will be broken by near-future Quantum-Computers, yet they do not provide PFS either.

Meshtastic's AES256 encryption is considered quantum-resistant[^1], but the public/private key exchange for DMs is not, as current quantum-resistant cryptography schemes don't fit in LoRa packets or our IoT hardware; realistic attack vectors include accidental mishandling of channel keys, nodes being lost, and potential future quantum attacks on DM key exchanges.

[^1]: On the Quantum-Resistance of AES256, see this stackoverflow question, containing a bit of debate and two good answers and the NIST's Post-Quantum FAQ section "To protect against the threat of quantum computers, should we double the key length for AES now? (added 11/18/18)"

Recommendations for users using private channels

Changes since 2.5.0 Firmware release

Integrity

Integrity means ensuring messages cannot be modified without the key.

Meshtastic does not verify the integrity of channel messages to check if they have been tampered with (see issue #4030 for details).

Recommendations

Changes since 2.5.0 Firmware release

Authentication

Authentication means nodes say who they are on the network. Meshtastic does not implement this, so it is trivial to impersonate anyone else if you have access to the channel key

This is because node IDs are based on hardware MAC address, which are hardcoded by the manufacturer.

Some other networks like Yggdrasil, cjdns, or libp2p use public/private key pairs, and the Public Key becomes the Node Identity. This makes all messages bigger and/or requires an interactive handshake process.

Recommendations

Changes since 2.5.0 Firmware release

Direct Messages

Direct Messages (DMs) are now implemented using Public Key Cryptography (PKC). This provides a significant upgrade in security compared to the previous channel-based encryption:

Prior to 2.5.0 Firmware Release

Previously, DMs were implemented as channel messages with a to protobuf field set. This meant anyone in the channel could read all your direct messages. With PKC, this issue is resolved, as only the intended recipient can decrypt and read the message.

Recommendations

Admin Messages

Admin Messages/Control are now protected by enhanced security features, making sure that critical operations within the network are more secure than ever before.

Prior to 2.5.0 Firmware Release

Previously, admin messages were not as secure, but with these updates, they are now much better protected against potential attacks and replay attacks.

Recommendations