What has to fit
A microcontroller runs firmware directly, often with no operating system, a small amount of RAM and flash, and a radio that shares both with everything else. End-to-end encryption on such a device is not one algorithm but a stack:
- Primitives. Key agreement (such as X25519), signatures (such as Ed25519) and authenticated encryption (such as AES-GCM or ChaCha20-Poly1305).
- Protocol state. Keys for each conversation or group, counters, and the state that lets keys change over time.
- The network around it. Framing, routing, retries and the radio driver.
The primitives are usually the easy part. The protocol state grows with the number of peers and groups, and it has to be stored, not just held in RAM. Memory figures depend on the part, the library and the protocol, so measure on the device you will ship rather than trusting a general number.
For parts where standard algorithms are too slow or too large, NIST ran a lightweight cryptography process for constrained environments. It selected the Ascon family in 2023 and published SP 800-232, covering authenticated encryption, hashing and extendable-output functions, on August 13, 2025.
Randomness is the first thing to get right
Every key a device generates is only as unpredictable as its random numbers. RFC 4086 warns that an attacker may find it easier to reproduce the environment that produced a secret than to search for the secret directly. A microcontroller that seeds its generator from a clock, a serial number or a fixed value is exposed to exactly that.
Use the part’s hardware random number generator, and check how its vendor says it must be configured. NIST SP 800-90B sets out design principles and validation tests for entropy sources, which is useful when choosing or qualifying one.
Timing, power and physical access
A device whose running time depends on secret data can leak that data. BearSSL’s documentation traces timing attacks back to Paul Kocher’s 1996 attack on RSA implementations and notes that many have since been demonstrated in lab conditions against symmetric and asymmetric systems. An embedded device can end up in an attacker’s hands, which makes measurement easier, so use libraries written to run in constant time.
Physical access also means keys can be read out of flash. Meshtastic’s documentation, for example, advises against configuring private channels on unattended nodes because it is easy to gain physical access and extract the channel key.
Energy is the other budget. A protocol that sends extra messages to change keys costs airtime and battery, and a device that sleeps for long periods misses group changes and must catch up when it wakes.
Storage and time
Key state changes as messages are sent and received. If power is cut halfway through saving it, the device can come back with an older state and reuse a nonce. RFC 9420 adds a random reuse_guard value to each encrypted MLS message to avoid nonce reuse in exactly that case of state loss or corruption. Make writes atomic and test what happens when power drops at every step.
Many protocols also check time. In MLS, a key package carries a lifetime with not_before and not_after values, and RFC 9420 requires a client to check that the current time is within that range in some cases. A device with no real-time clock needs to be given the time from somewhere it trusts.
How existing projects divide the work
Projects make different trade-offs. Meshtastic’s documentation (the version 2.8 docs) describes AES256-CTR encryption of packet payloads with a key per channel, packet headers sent unencrypted so that nodes can relay packets they cannot decrypt, and, since firmware 2.5, public key encryption and signatures for direct messages. The same page lists perfect forward secrecy as missing and says channel messages are not checked for integrity.
Another approach keeps the heavy group operations off the microcontroller. In Offline Protocol, offline-protocol-leaf is a Rust firmware component that builds without the standard library and takes part in MLS as a member that never issues commits. A full peer, such as a phone or a Linux host, creates the group and performs membership changes. Two leaves cannot set up a session with each other, so each one pairs with a full peer over a radio path the firmware supplies.
The answer to the question is yes, with conditions: a source of real entropy, constant-time code, careful storage, a trusted time at pairing, and a clear decision about which device manages the group. For the group protocol itself, see using MLS for group messaging on mobile, and for the ways encrypted messaging fails in practice, see what can go wrong with mesh messaging encryption. If the device needs to reach a phone directly, sending data from an ESP32 to a phone covers the links.