Exchange a key. Send an encrypted message.

• Flash. Flash at -O3 is 80.5 kB for ML-KEM-768 and 106.7 kB for ML-DSA-44. Built for size (-Os, built, not run) it is 9.4 kB and 13.3 kB.
• Wire size. 2.2 kB crosses the wire (1.2 kB public key plus 1.1 kB ciphertext) against 64 B for X25519 (32 B each way). Over a radio with small packets that is many more packets: about 10 Bluetooth LE packets of 244 B against 2 (computed, not measured).
• Integration. Initialize the TRNG driver yourself; the SDK's Board_init() does not. The libraries (mlkem-native 2.0.0, mldsa-native 2.0.0) are unmodified portable C and keep their working buffers on the stack by default. ML-DSA signing time varies from message to message (77 to 361 ms over 16 messages, mean 154 ms) because it retries until a check passes.

ML-KEM-768 key agreement between the board and a Mac, then one line the Mac encrypted with AES-128-GCM under the agreed key, decrypted and authenticated on the board.

Transport. USB serial through the board's built-in XDS110 debugger (its backchannel UART), 115,200 baud, 8N1. Every byte is sent as two hex characters, so 2.3 kB of payload in all (the 2.2 kB of key material plus the encrypted message) took 4,864 characters on the wire. Frame format: @PK, @CT, @KEY, @MSG, @DONE lines, each with a CRC-32 (portability/pqc-join/core/pqc_join.h). The Mac side is tools/pqc_join/mac_side.py with OpenSSL 3.5 or newer (the Mac's built-in /usr/bin/openssl is LibreSSL and cannot do ML-KEM).

1. The board makes an ML-KEM-768 key pair from 64 bytes of its hardware random-number generator (20 ms for the bytes, 21 ms for the key pair); the 2.3 kB private key stays on the chip
2. The board sends its 1.2 kB public key (2,389 characters as hex, about 207 ms at 115,200 baud, computed)
3. The Mac wraps a fresh secret with that key (58.6 ms, including starting OpenSSL) and sends back the 1.1 kB ciphertext
4. The board unwraps it and turns the secret into an AES-128 key with HKDF-SHA-256 (29.8 ms on the board); both sides show the first 4 bytes of a hash of that key, and they match
5. The Mac sends one 76-byte line encrypted with AES-128-GCM; the board decrypts it in software (2.5 ms), checks the tag and prints it

One row per board, one cell per operation. RAM needs differ by code. About 14 kB is the peak stack measured for PQClean on the RP2040 (arXiv 2603.19340). About 19 kB is an estimate for mlkem-native: its published 14 kB plus the 2.3 kB, 1.2 kB and 1.1 kB keys and ciphertext. Cells without a measured row are estimated from cycle counts published for other cores. Each cell cites its source.

Not for this chip the chip does not have the RAM for itWorks measured on a board; the detail is in the table above. Every other cell is estimated.

Chips with an AES block run it far faster than software: the MSPM33 C321A runs AES 41.7 to 41.9 times faster at 1 kB. A block's win is largest on large data and shrinks on a single 16-byte block. The CRC block gains a few times, because the CPU still feeds it word by word. Each figure is hardware cycles against a software library on the same chip, from data/results/. A row range means the rows differ by key-setup handling or code variant.

In TI's tables a post-quantum signature check (ML-DSA-44 verify, 98 ms) is faster on the MSPM0G3519's Cortex-M0+ than the classical one it replaces done in software (ECDSA P-256 verify, 716 ms). The cost is size: keys and ciphertexts of 800 to 4.5 kB instead of 32 to 64, and tens of kilobytes of RAM.

Published figures for these operations on comparable cores, as each source states it. Different code, compilers and clocks, so compare cycles within one source before comparing across sources.

Why does the board stop at "join: making an ML-KEM-768 key pair"?

Call TRNG_init() before TRNG_open(), and stop with a message if TRNG_open() returns NULL. An image that skips TRNG_init() stops here; the SDK's Board_init() starts only the power and GPIO drivers. The TRNG is the chip's hardware random-number generator, which the key pair needs. The debugger showed the CPU in an exception handler, PC 0x100006f4 and LR 0xfffffff9 (observed 2026-10-08, not saved). cc1354p10/pqc-join/README.md, the TRNG section.

Can someone in the middle read the message?

Someone who only listens cannot. They see the public key and the ciphertext, and ML-KEM-768 is built so that does not give away the key. Someone who can change bytes on the wire can. They answer the board with their own key and the Mac with theirs, and each side agrees a key with them. Do not ship it as is: the demonstration has no signature step. A product signs or pins the keys, for example with ML-DSA-44, whose signing is measured above.

What does the key check line mean, and what would MISMATCH mean?

Each side prints the first 4 bytes of a hash of the key it holds (tools/pqc_join/mac_side.py). MATCH means the two are equal, so both sides almost certainly hold the same key, and the decryption tag passing confirms it. MISMATCH would mean they derived different keys and the board's decryption would fail its tag check. Every saved run printed MATCH; a MISMATCH has not been seen here.

Why does the demo need a USB hub the Mac can switch?

This board's debugger connects only in the first seconds after power-on, so run.sh switches the port off for 6 s and on again before each load. Install uhubctl (brew install uhubctl) and run it alone to list hubs; one marked ppps can switch its ports. Here that was the USB-A port of Apple's USB-C Digital AV Multiport Adapter. No manual unplug and replug was done. cc1354p10/FAQ.md.

Are any of these numbers measured by Fox Red Labs?

Some are. Measured by us: 111 results on 7 boards (CC1354P10-1, CC2755P10, MSPM0 G3519, MSPM0 G5187, MSPM33 C321A, NUCLEO-U083RC, SK-TDA4VM), in the Measured by us table above, with 47 peak-stack measurements shown beside them. The other times are TI's published figures or estimates. Every cell marked Not run is TI's published figure or an estimated range, and the "published by others" table is exactly that.

Why can the MSPM0 L1306 and MSPM0 C1104 not do post-quantum key exchange?

RAM. The smallest portable ML-KEM-768 found needs about 14 kB of working RAM (PQClean on the RP2040, arXiv 2603.19340); the MSPM0 L1306 has 4 kB and the MSPM0 C1104 has 1 kB, less than one 1.2 kB public key. The answer is no for the MSPM0 C1104 (its RAM is below the size of one public key). For the MSPM0 L1306 the answer is expected to be no: it comes from published RAM needs, not from a build.

Why does the CC2340R5 fit ML-KEM alone but not beside Bluetooth?

ML-KEM-768 with mlkem-native needs about 19 kB of working RAM (an estimate). TI's basic Bluetooth example leaves 5.1 kB of the chip's 36 kB. So room is expected only without the Bluetooth stack. That is one TI example configuration; a trimmed Bluetooth build or a lower-RAM ML-KEM was not built.

Is post-quantum slower than what it replaces?

In TI's own tables, not for checking signatures: ML-DSA-44 verify is faster than ECDSA P-256 verify on both chips TI lists. Signing is slower. Every key, ciphertext and signature is 20 to 72 times bigger, which costs more on a radio link.

Why do ML-DSA signing times differ so much between TI's cores and runs?

Signing repeats an internal try until a check passes, so its time varies from run to run. The RP2040 paper saw 66 to 73 percent spread, and TI averages only 16 signs. TI's own ML-DSA-44 sign mean is 40.4M cycles at 32 MHz but 33.9M cycles at 80 MHz on the same chip (TI's MSP Crypto Library 0.33.00.07 user guide, MSPM0 SDK 2.11.00.07, performance tables). The difference is probably run-to-run noise (suspected, not repeated). Verification time is fixed. TI's runs were not repeated here.

Why does the MSPM0 G3507 fit ML-DSA signing only in low-RAM mode?

The default mode of mldsa-native needs 43.4 kB for signing, more than the chip's 32 kB. Its low-RAM mode needs 9.6 kB, or about 14.4 kB with the 2.5 kB private key and 2.4 kB signature added, and trades speed for memory by an amount nobody has published. This is an estimate from published figures, not a build.

Why does this page give both 14 kB and 19 kB for ML-KEM-768?

They are different code. About 14 kB is the peak stack measured for PQClean on the RP2040 (arXiv 2603.19340). About 19 kB is an estimate for mlkem-native: its published 14 kB for decapsulation plus the keys and ciphertext (2.3 kB, 1.2 kB and 1.1 kB).

What does "No estimate" mean?

There is no estimate or test for that board and operation.

Measured by us: 111 results on 7 boards (CC1354P10-1, CC2755P10, MSPM0 G3519, MSPM0 G5187, MSPM33 C321A, NUCLEO-U083RC, SK-TDA4VM), in the Measured by us table above, with 47 peak-stack measurements shown beside them. The other times are TI's published figures or estimates. Researched 2026-10-09; each figure cites its source. Terms: vocabulary.

Four kinds of evidence on this page

• Demonstration, ran end to end: The exchange above, on one board, once, on 2026-10-08.
• Known-answer check, NIST vectors passed: ML-KEM-768 and ML-DSA-44 outputs match NIST's fixed inputs byte for byte, on the board, before timing.
• Measurement, cycles and stack: Times from the CPU cycle counter and stack from painting it, in the Measured by us table above.
• Assurance, none claimed: No side-channel testing, no certification (such as FIPS 140-3), no review. Nothing here says the project is secure.

A cell marked "Chip limit" means the chip cannot hold the code in its RAM or flash. Only rows marked as measured are measurements made here; none of them is a security claim.

Words used below, once: Cortex-M0+ is a small Arm core with no FPU (floating-point unit); Cortex-M33 is a faster Arm core; C28x is TI's control-processor core; PKA is hardware that speeds up elliptic-curve math. Encapsulation: the sender wraps a fresh secret with the receiver's public key, which gives a ciphertext (the wrapped secret); decapsulation unwraps it. kcycles means thousands of clock cycles. pqm4 is an open-source collection of post-quantum code for Cortex-M4 chips (m4fspeed is its speed-tuned assembly build); liboqs is an open-source post-quantum library; uint8_t is C's 8-bit integer type. 1 kB = 1,024 bytes.

ML-KEM (Kyber)

NIST's post-quantum key exchange (FIPS 203). One side publishes a public key; the other uses it to wrap a fresh shared secret (encapsulation) and sends back a ciphertext; the first side unwraps it (decapsulation). The number (512, 768, 1024) is the strength level.

ML-DSA (Dilithium)

NIST's post-quantum signature (FIPS 204), used to prove firmware or a message came from the right key. 44, 65 and 87 are its strength levels.

ECDSA P-256, X25519

Today's elliptic-curve signature and key exchange; a large enough quantum computer could break both.

TRNG

True random-number generator: the chip's hardware source of random bytes, which the key pair needs.

HKDF-SHA-256

A standard way to turn the shared secret from the exchange into an AES key of the right length.

PKA

Public-key accelerator: hardware on the MSPM33C321A that speeds up the elliptic-curve math.

kcycles

Thousands of clock cycles. Divide by the clock in MHz to get milliseconds.

mlkem-native, mldsa-native

Portable open-source C versions of ML-KEM and ML-DSA that run on any of these cores; TI's library covers only the MSPM0G3519 and MSPM33C321A.