Flash and RAM are different budgets
Microcontroller memory comes in two budgets that run out separately. Flash (or ROM) holds the code and constant data. RAM holds the variables, buffers, stack and any state that changes. Mbed TLS’s documentation draws the same line, calling the first the binary footprint and the second the memory footprint.
Both budgets are small on a constrained device. RFC 7228 describes a Class 1 device as having about 10 KiB of RAM and about 100 KiB of code space, and says such devices cannot easily use a full stack with TLS, though they can run protocols designed for constrained nodes along with the security functions a large network needs. Encryption has to share those budgets with the radio stack, the application and everything else.
What library documentation states
Several libraries publish figures for themselves. Each comes from the vendor, for a configuration the vendor chose, so treat them as indications of scale, not as comparable benchmarks.
| Library | What its documentation states | Conditions it gives |
|---|---|---|
| BearSSL | A minimal server implementation “may fit in about 20 kilobytes of compiled code and 25 kilobytes of RAM” | A minimal TLS server; given as an example |
| wolfSSL | Minimum footprint of 20-100 kB; runtime memory of 1-36 kB | Depends on build options and operating environment; runtime memory depends on I/O buffer sizes, public key algorithm and key size |
| Monocypher | Under 2000 lines of code; binaries “can be under 50KB” | A cryptography library, not a TLS stack |
| Mbed TLS | Default 16 KB frame buffer for incoming and outgoing TLS data | A TLS standard requirement; can be reduced when you control both sides or know the largest frame |
The ranges are wide because the libraries are configurable, and because a TLS stack and a bare cryptography library do different jobs.
Where the memory goes
The cipher code itself is only one part of the total. Library documentation points to the other costs:
- Message buffers. A protocol that can receive a large record needs a buffer that holds it. Mbed TLS uses a 16 KB frame buffer by default because TLS requires it, and says you can safely reduce it, for example to 2 KB, if both sides support the maximum fragment length extension or you know the largest frame that will ever be sent.
- Public key arithmetic. Elliptic curve and RSA operations need working memory. In Mbed TLS, the elliptic curve window size defaults to up to 6 and can be reduced to 2, using less memory at the cost of speed.
- Tables. Mbed TLS builds AES tables in RAM the first time AES is used, or can store them in ROM instead, a direct trade between the two budgets.
- Heap and stack. BearSSL has no dynamic allocation at all, which its documentation says makes it immune to memory leaks and stops outsiders from making it allocate large amounts of RAM. Libraries that do allocate need a heap sized for their peak.
- Protocol state. Keys, counters and session data persist between messages. BearSSL’s session cache needs 100 bytes of RAM per remembered session. Group protocols hold more: RFC 9420 assumes each MLS member keeps a complete view of the public state of the group’s ratchet tree, including public keys and credentials, plus its own copy of the key schedule for each epoch. That state grows with the group.
One reported example
Offline Protocol’s site reports that its reference no_std leaf, which speaks MLS and targets a Cortex-M33 class part, links at 449.5 KiB of flash in a reference build. The same page notes that linking establishes flash use, while peak heap, stack, radio timing and energy come from running the actual board, and that the figure is a snapshot that changes with SDK and compiler versions. Measure your own build on your own part rather than relying on this figure.
How to measure your own
- Fix the configuration. Choose the algorithms, key sizes, buffer sizes and protocol features you will ship, and disable the rest.
- Read flash from the linker. The linked image shows what the code and constant data cost.
- Measure RAM while running. Record peak heap and stack during the heaviest operations, such as pairing, receiving the largest message, responding and changing keys.
- Test the largest case. Use the biggest group, longest certificate chain or largest message the device must handle.
- Budget for everything else. The same flash also holds the radio stack, operating system, bootloader, a second image slot if you update firmware with a fallback, storage and the application.
Whether the result fits is only part of the answer. Running encrypted messaging on a microcontroller also needs a real entropy source, constant-time code and storage that survives power loss.