PKC Direct Messaging (v2.5+)

Meshtastic firmware 2.3v2.5 introduced PKI-basedPublic encryptionKey forCryptography (PKC) encrypted direct (person-to-person)messages messages. This is— a significant security upgrade that provides forward secrecy formakes DMs —genuinely somethingend-to-end encrypted rather than just channel-scoped.

Note on terminology: This feature is officially called "PKC Direct Messages" or "encrypted direct messages" in Meshtastic documentation. It was introduced in firmware v2.5, not possiblev2.3 as some sources incorrectly state.

Before v2.5: How DMs Worked

Prior to v2.5, "direct messages" in Meshtastic were standard channel messages with a to field set to the recipient's node ID. Anyone on the same channel PSKwith the channel key could decrypt and read all DMs. There was no per-recipient encryption.

Howv2.5+: PKIPKC DMsEncrypted WorkDirect Messages

EachFrom Meshtasticv2.5 onward, direct messages use per-node generatesasymmetric a unique Curve25519 keypair on first boot:encryption:

• Key generationexchange: X25519 ECDH — Nodeeach generatesnode ahas an X25519 public/private key (stored locally, never transmitted) and a public key.pair
• KeyEncryption: exchangeAES-CCM — Eachusing nodethe broadcastsderived itsshared secret as the key

Only the intended recipient can decrypt the message — the channel key is not used Node public keykeys asare partdistributed ofautomatically itsvia nodeNodeInfo info advertisement. Other nodes store this public key in their node database.packets Message encryption

Backward —Compatibility

When

If you send a PKC-encrypted DM to anothera node,node running firmware 2.4.3 or older, Meshtastic performsautomatically anfalls ECDHback key exchange using your private key andto the recipient'legacy channel-based method. The sender's publicapp key,indicates derivingwhich a unique shared secret. This shared secretmethod is usedbeing as the AES session key for that message.

Forward secrecy — Each message (or message session) can use a fresh key derivation. If a session key is compromised, it does not expose past messages. used.

Requirements for PKI DMs

• Both sender and recipient must be running Meshtastic firmware 2.3v2.5 or later

The recipient's public key must be in the sender's node database (requires having received at least one advertisement from the recipient node) Both nodes must behave onexchanged compatibleNodeInfo channels (or direct radio range) for key advertisements to propagate

Enabling and Verifying PKI DMs

PKI DMs are enabled by default in firmware 2.3+. No configuration is required. The Meshtastic app shows a lock icon or "encrypted" indicator on DMs that use PKI encryption. If the recipient's public key is not yet known, the app may fall back to channel-encrypted DMs or prompt you to wait for a key exchange.

Comparison: PSK Channel vs PKI DM Security

PropertyPSK ChannelPKI Direct Message Encryption algorithmAES-256-CTRECDH + AES-256-CTR Key exchangeManual (share PSK)Automaticpackets (public keys viaare mesh)included Forwardautomatically) secrecyNoYes Who can readAnyoneCompatible with PSKOnlyAndroid, senderiOS, and recipientPython KeyCLI compromiseclients exposureAllthat pastsupport v2.5+

Source: meshtastic.org/docs/overview/encryption/ and futuremeshtastic.org/blog/introducing-new-public-key-cryptography-in-v2_5/. messages

LimitedVerified to compromised session Firmware requirementAny2.3+

Practical Recommendations

For sensitive one-on-one communication, use DMs with firmware 2.3+ on both ends For group communication, use a custom channel with a randomly generated PSK distributed via secure channels Never put truly sensitive information on the Default channel — it is effectively unencrypted Rotate channel PSKs periodically for long-running networks where membership changes 2026-05-03.