Meshtastic: decrypt and decode packets (host-tested) #24

New Issue

2026-10-05T20:07:15Z

twisla commented

2026-10-05 20:07:15 +00:00

What

The part of the Mesh Protocol that turns received bytes into messages, as a host-tested library next to lib/meshtastic: decrypt the payload with the Channel's key, decode the protobuf inside, and recognise packets already seen.

What's known

M3 already reads the header (lib/meshtastic/src/meshtastic_header.h): sender, receiver, packet ID, hops, channel hash. The payload after it is encrypted.
Encryption: AES in CTR mode, AES-128 or AES-256 by key length. The nonce is the packet ID (as 64 bits, little-endian), then the sender's node number (32 bits), then 4 zero bytes. The default key is public (kDefaultKey in meshtastic_presets.h). mbedTLS, already in the firmware, has AES, hardware-accelerated on the ESP32-S3.
Which Channel: the header's channel hash picks the candidate keys; a wrong key gives bytes that don't parse.
Protobufs: Meshtastic's published .proto files (GPL-3.0, as this project) with nanopb (ADR 0001). The payload is a Data message with a port number: text (1), position (3), node info (4), routing (5), telemetry (67).
Duplicates: the same packet arrives several times as Nodes relay it; (sender, packet ID) identifies it.
Fixtures: real packets captured from the reference node (#22) are the tests. Nothing was heard in M3 to use instead.

Questions

nanopb's generated code or hand-written decoders for the few messages we need? Compare flash and RAM.
How the protobuf definitions are kept in step with upstream: a pinned copy in the repo, with its version recorded?
How many recent packet IDs to remember for duplicates, and for how long.
Recent firmware encrypts Direct Messages with public keys: how are those recognised and reported, while we can't read them?

## What The part of the Mesh Protocol that turns received bytes into messages, as a host-tested library next to `lib/meshtastic`: decrypt the payload with the Channel's key, decode the protobuf inside, and recognise packets already seen. ## What's known - **M3 already reads the header** (`lib/meshtastic/src/meshtastic_header.h`): sender, receiver, packet ID, hops, channel hash. The payload after it is encrypted. - **Encryption:** AES in CTR mode, AES-128 or AES-256 by key length. The nonce is the packet ID (as 64 bits, little-endian), then the sender's node number (32 bits), then 4 zero bytes. The default key is public (`kDefaultKey` in `meshtastic_presets.h`). mbedTLS, already in the firmware, has AES, hardware-accelerated on the ESP32-S3. - **Which Channel:** the header's channel hash picks the candidate keys; a wrong key gives bytes that don't parse. - **Protobufs:** Meshtastic's published `.proto` files (GPL-3.0, as this project) with nanopb (ADR 0001). The payload is a `Data` message with a port number: text (1), position (3), node info (4), routing (5), telemetry (67). - **Duplicates:** the same packet arrives several times as Nodes relay it; (sender, packet ID) identifies it. - **Fixtures:** real packets captured from the reference node (#22) are the tests. Nothing was heard in M3 to use instead. ## Questions 1. nanopb's generated code or hand-written decoders for the few messages we need? Compare flash and RAM. 2. How the protobuf definitions are kept in step with upstream: a pinned copy in the repo, with its version recorded? 3. How many recent packet IDs to remember for duplicates, and for how long. 4. Recent firmware encrypts Direct Messages with public keys: how are those recognised and reported, while we can't read them? ## Related `lib/meshtastic`, `lib/lora/src/packet_view.cpp`, ADR 0001, #22, #23.

twisla added this to the M4 Mesh receive milestone 2026-10-05 20:07:15 +00:00

twisla added the

concern/memory concern/security labels 2026-10-05 20:07:15 +00:00

twisla added a new dependency 2026-10-05 20:07:15 +00:00

#22 Hardware: a reference Meshtastic node