Classical cryptographic message-size and link estimates, not measured hardware performance.
In this article
LuniQ Fit Guide: Compare Crypto Bytes, Frames and Modeled Link Time
This walkthrough uses LuniQ Fit to compare hypothetical message packaging. It is an educational engineering estimate. No real bus, radio, endpoint or quantum device is contacted, and the time estimates are not measurements from your hardware.
Step 1: Pick the transport
Start with Transport and read the settings that appear beneath it. Choose the link that matches the question you are exploring rather than the one that produces the smallest number. The supported choices cover several very different cases, including constrained buses, radios, network payloads and QR capacity.
Check the units and the assumed payload limit. A link rate does not by itself describe how many application bytes a frame can carry. Settings such as data rate, frame payload or radio configuration change the calculation and should be recorded with any exported result.
Step 2: Account for fragmentation fields
Set the fragment-header bytes that your design would add for sequencing or reassembly. Treat that value as an explicit application assumption. It is not automatically the full protocol overhead of every transport and should not be chosen merely to make the result fit.
A fragmented message needs more than a frame count: actual designs also need reassembly bounds, loss handling, ordering and timeout behavior. This calculator does not implement or validate those functions. It helps you see where to ask the next engineering question.
Step 3: Specify the cryptographic object
Choose what you send in the What you send section. A signature, public key, key-encapsulation message or certificate-like object has a different purpose and size. Include the application payload and any applicable certificate or encoding allowance shown by the controls.
If a setting allows multiple application messages per signature, understand what grouping means for your protocol. Sharing a signature across a group can change packaging, but the calculator does not establish whether that construction meets your authentication or freshness requirements.
Step 4: Read the comparison table correctly
The table separates algorithm, standard/status, crypto bytes, total bytes sent, frames, modeled time and comparison with a classical row. Keep those columns distinct. Crypto bytes are not the complete transmitted message; a frame count is not a reliability measure; modeled bus time is not cryptographic execution time.
For standardized mechanisms, inspect the primary references: ML-KEM / FIPS 203, ML-DSA / FIPS 204 and SLH-DSA / FIPS 205. Read each row's status instead of assuming that every comparison entry has the same standardization or approval status.
Step 5: Vary one assumption
Try a smaller frame payload, a different fragment-header allowance or another parameter set. Observe which changes increase frame count and which only alter the modeled time. Preserve a consistent application message while making the comparison.
Do not choose an algorithm solely because it uses fewer bytes in this scenario. Security requirements, implementation maturity, interoperability, actual processor cost and system policy are separate inputs to a real engineering decision. The table cannot establish that two rows provide equivalent properties for your deployment.
Step 6: Explore the TLS first-flight panel
Select the key-exchange and certificate-signature choices, the number of certificates and the additional options shown in the TLS section. Read the result as a modeled first-flight estimate under those assumptions. It is not a packet capture, a browser negotiation log or a guarantee about every TLS implementation.
A real verification step would use representative certificates and implementation settings on the target stack. The calculator can help define that test, but it does not run it for you. Save the scenario so a later measurement has a clearly described reference.
Step 7: Export and verify outside the calculator
Use Download report to keep the selected assumptions and result. Review the notes and tips alongside the numeric table. Static page requests reach the host, while the calculation and explicit download run in the browser without uploading a system configuration.
The report is a planning artifact, not a security certification or an implementation approval. For the wider rationale behind byte budgeting and the difference between modeled and measured time, continue with the LuniQ Fit article.