The letter goes in the envelope, not in the pen.
Think of registered mail. You write the letter with any pen and only then put it in the envelope, glue it and seal it. Nobody mixes the ink with the wax, because then nobody could check either the letter or the seal.
We did the same with telemetry. The codec (the program that compresses) stays exactly as it was: it produces the same file on any machine and can be audited byte by byte. Encryption lives in the envelope, which wraps what the codec produces. Cryptography in the envelope, never in the codec.
And one detail decides everything: the tolerance (the "never off by more than X" that gives the file its value) goes inside each block’s seal. If someone in transit changes that number to make a bad file look good, the seal no longer matches.
Three layers, and only two need a new lock.
Blocks of readings. Each block (a stretch that opens on its own) is encrypted with AES-256 and gets a 16-byte seal. If a radio packet is lost, only that block is lost; and you can open a stretch in the middle without opening the rest. AES-256 already resists a quantum computer: the best known attack (Grover) only halves its security, which still leaves a huge margin.
Session key. The key that encrypts the blocks comes from a double exchange: X25519, today’s lock, together with ML-KEM-768, the new key exchange standardized by NIST (FIPS 203). If one falls, the other holds. It costs 2,304 bytes per key exchange, paid once per session, not per block.
Signed manifest. The list of what was sent (cases, channels, tolerances) is signed with ML-DSA-65, NIST’s new digital signature (FIPS 204): 3,309 bytes per session. With it, whoever signed cannot later deny the tolerance they declared.
Compression’s success is what exposes the seal.
With ordinary compression, 2 to 5×, 16 bytes per block don’t show up in the bill. TUBE doesn’t work in that regime: the more it compresses, the smaller each block gets, and the larger the seal’s relative weight.
In practice: on an energy meter the seal adds 4%; on a drone it nearly doubles the file; on the satellite, the average block holds about 12 bytes of data, less than the 16-byte seal itself. In all 15 cases the decrypted file was opened and the tolerance checked: the guarantee crosses the envelope intact.
| Case | Seal cost | Reading |
|---|---|---|
| Energy meters (AMI) | +4.4% | fat block: the seal disappears |
| Real ECG | +10.3% | dense data: still modest |
| Real robot (ROS 2) | +16.5% | 21× compression |
| Motion capture (CMU) | +17.3% | 22× compression |
| ALOHA robot arm | +28.8% | 37×; thin blocks |
| Drone (PX4) | +97.6% | 123×: nearly doubles the file |
| Satellite | +126.1% | average block of ~12 B, smaller than the seal |
| Robotics (extreme case) | +172.2% | the seal costs 1.7× the data |
The seal must be the size of what gets lost.
Sealing each block looked like the obvious choice, and the measurement showed it is only right when blocks are fat. The right thing is to match the seal to the link’s unit of loss: if the radio loses whole packets, seal the packet (a batch of blocks) with a single seal. The seal is diluted across the batch, and loss stays limited to what the link would lose anyway.
This variant is the design answer to the finding. It has not been measured yet: its honest number is the next step, not a promise on this page.
Expensive, hostile, long-lived links.
Makes sense
- Satellite downlink: data that spends years in transit and in archives, recorded by whoever listens to the sky.
- Field radio and fleets: telemetry from machines, drones and robots crossing third-party networks.
- Regulated audit: when the tolerance is a contract and must reach the auditor intact.
Not needed
- Data worth minutes: if nobody cares about it in 10 years, today’s lock is enough.
- Short closed network: inside a single building, with no outside recording, the risk is different.
- Modest compression: at 2–5×, per-block sealing works without this page’s problem.
A stretch of the series that opens on its own, without the rest. It is the unit TUBE compresses, and here the unit that gets encrypted.
The 16 bytes that prove the block arrived unchanged. If one bit changes in transit, the seal doesn’t match and the block is rejected.
Two locks at once, today’s and the new one. To open it, you have to break both.
Where this could be wrong.
Size talks
Encryption hides content, not size. Since TUBE only sends data when the signal changes, anyone watching the link sees when the robot moves or the satellite maneuvers, without decrypting anything. Padding fixes it, and costs exactly what compression saved. Not measured; declared.
Prototype, not product
The numbers come from a prototype with the full round trip checked on the 15 cases, not from a hardened implementation audited by third parties.
Per-packet sealing is unmeasured
It is the design answer to the finding. Until measured, it stands as a hypothesis.
New locks are new
ML-KEM and ML-DSA rest on a different math problem, studied for less time. Attack claims appear and need community verification; that is why the key exchange is hybrid: with X25519 alongside, a break of ML-KEM does not open the session to someone without a quantum computer.
Compressed, encrypted and auditable, all three at once.
If your telemetry crosses a hostile link and must stay auditable on the other side, this is the problem we are measuring. The first step is TUBE: you send a telemetry file and get the numbers back within a week, installing nothing.
← Post-quantum · stickybit.com.br
- tubesec prototype in Stickybit’s telemetry repository (
go run . -sec): envelope, bytes per layer and seal cost on the 15 TUBE test cases. - NIST FIPS 203 (ML-KEM) · NIST FIPS 204 (ML-DSA), August 2024.
- Previous page: "Post-quantum cryptography on 100× compressed telemetry" (
/tubesec-pqc/).