Classical cryptographic message-size and link estimates, not measured hardware performance.
In this article
LuniQ Fit: Post-Quantum Cryptography Has a Message-Size Problem Too
Choosing a cryptographic mechanism is only part of an engineering migration. The bytes still have to cross a link, fit inside a protocol and arrive within the system's constraints. LuniQ Fit explores that packaging problem with classical calculations using selected algorithm sizes and transport assumptions. It does not run a quantum computer, benchmark a target processor or certify a secure protocol.
What changes when the cryptographic object grows?
A signature, public key, key-encapsulation object and certificate are not interchangeable payloads. Their sizes can differ by algorithm and parameter set. Adding application data, certificates and encoding fields can create a much larger message than looking at one cryptographic object in isolation suggests.
The tool lets you choose what is being sent and compare candidate mechanisms under the same transport assumptions. Its purpose is to reveal questions such as how many frames a payload needs, how much modeled bus time or airtime that implies, and whether a first-flight size estimate warrants a closer integration test.
Why transport assumptions matter
A raw cryptographic byte count does not equal useful payload capacity. A frame may need sequencing headers, protocol fields and other overhead. Some transports offer different limits depending on settings. The application includes choices for MIL-STD-1553, CAN, LoRaWAN, Bluetooth LE, UDP, QR and TLS-oriented examples, each with its displayed assumptions.
Fragmentation also creates engineering work beyond arithmetic. The receiving side needs a reassembly policy, resource bounds, timeout handling and a way to deal with missing pieces. LuniQ Fit does not deploy those mechanisms. A result that fits in a modeled number of frames is not proof of end-to-end reliability or safety on a real system.
Where the cryptographic standards enter
NIST's FIPS 203, FIPS 204 and FIPS 205 specify ML-KEM, ML-DSA and SLH-DSA respectively. A key-encapsulation mechanism and a digital signature solve different problems, so a size comparison must preserve that distinction.
Read the standard/status column for every row. The calculator can include comparison entries whose standardization status differs; appearance in a table does not make every candidate a finalized NIST standard. Nor does a smaller row automatically imply an equivalent security level, an approved choice or better performance on your hardware.
When a quick calculation is valuable
Use the tool early enough that a packaging constraint can still influence architecture. A hypothetical device with a limited frame payload may need a different message design from a server that normally sends larger records. Both can benefit from a transparent estimate before anyone spends time integrating a full stack.
Change one link setting at a time. Compare bytes, frames and modeled time, then write down which assumptions dominate the result. The calculation does not include every scheduler delay, retry, implementation cost or operating condition. Its time columns are modeled link estimates, not measured signing speed or hardware benchmarks.
The TLS panel is a model, not a handshake capture
The TLS section combines selected key exchange, certificate-signature and chain assumptions into an estimate. Actual handshakes depend on implementation details, extensions, certificates, compression choices and the surrounding network. Treat this panel as a way to identify a question for packet capture and integration testing, not as a record of packets sent by the browser.
This also separates post-quantum engineering from quantum computing. The tool's connection to quantum is the cryptographic migration problem it helps examine; its calculations run classically. That is an honest reason to keep it in the Quantum readiness area while moving generic scheduling tools into Tool Hub.
How to use the output responsibly
Export a report with the scenario assumptions, preserve the source standards you checked and verify a representative message on the actual target system. Keep size, security, compatibility and measured performance as separate evaluation dimensions. The Fit guide walks through those controls without treating the smallest number as a design recommendation.