Latency and Throughput

When designing a cryptographic solution, a simple rule of thumb often arises: hardware is faster and more secure than software. However, such a statement is too broad. Hardware and software possess different characteristics and optimization potential, as well as differing costs regarding modification, maintenance, and protection. Therefore, comparing a single throughput figure is insufficient for making a decision. One must also consider latency, determinism, resource consumption, updateability, costs, resilience against errors and attacks, error and attack detection capabilities, and—above all—the requirements of the specific application.
Moreover, the boundary between hardware and software is blurring in practice. Software can utilize processor instructions designed for cryptography, a specialized accelerator, or other hardware resources. Conversely, programmable hardware may incorporate relatively general-purpose logic. It is therefore more meaningful to compare specific architectures rather than the abstract categories of "hardware" and "software."

Hardware and Software Implementations

Differences exist between hardware and software implementations of cryptographic algorithms regarding performance, latency, cost, updateability, error detection methods, and security features. However, without specific measurements, it is impossible to reliably determine which variant is more suitable for a given system.
Furthermore, manufacturers may not disclose all the parameters necessary for a true assessment. The nominal throughput of a cryptographic accelerator does not necessarily correspond to the throughput of the entire system. The result can be influenced by memory-to-accelerator transfers, request queues, synchronization, the network interface, the operating system, or resource sharing among multiple applications.

The table does not indicate a universal winner. The choice of architecture must be based on the required combination of performance, latency, security, flexibility, and lifecycle.

Throughput is not latency

Throughput indicates the amount of data an implementation can process per unit of time. Latency, on the other hand, represents the time from the generation of a request or data block to the moment the result becomes available. These metrics are not interchangeable. A parallelized implementation can achieve very high aggregate throughput, yet an individual request may still require a relatively long time due to computation initialization, synchronization, memory access, waiting for the accelerator, or the completion of subsequent operations.
With symmetric algorithms, hardware acceleration enables high throughput, especially when processing large blocks or multiple parallel streams. Operations based on public keys, key exchange, digital signatures, or signature verification have a different computational nature, and their latency can be more significant. Therefore, when evaluating performance, it is insufficient to look merely at clock frequency or the nominal number of cryptographic operations. The result is influenced by factors such as:

• the number of parallel computing units,
• data path width,
• cache size and hierarchy,
• memory subsystem throughput,
• DMA transfers,
• request queues,
• interrupts,
• accelerator sharing,
• synchronization between the CPU, accelerator, and network interface.

In the case of software, additional factors come into play—such as the operating system, thread scheduling, context switching, virtualization, and other mechanisms—which can introduce a variable component to latency. From a security perspective, it is therefore advisable to monitor not only the average operation time but also the variance and, for instance, the upper quantiles of latency. A system with a very short average operation time may be unsuitable for time-critical applications if, under certain circumstances, it exhibits a significantly longer response time.

Datapath and AES Example

When designing a specialized cryptographic datapath, performance can be scaled by adjusting the datapath width. However, the following values should be viewed as an illustrative example rather than a universal benchmark for a specific ASIC.

The table shows that a wider datapath can reduce the number of clock cycles required to process a block. At the same time, however, implementation complexity increases, and overall system latency cannot be directly inferred from these figures alone. For instance, if we consider a model accelerator operating at 1 GHz, the given clock cycle counts yield approximately the following values:

These values describe only the cryptographic operation itself within the given model. They do not include data transmission, queuing, memory access, synchronization, or other system components. Therefore, they should not be confused with end-to-end latency.

End-to-end latency

In remote control or data processing scenarios, the entire chain must be considered. When data is transmitted between devices, cryptographic protection can be applied either before transmission or after data reception. In remote decision-making, a similar process occurs in the reverse direction as well. A model example might look like this:

1. data acquisition from the sensor (1.0 µs) – digitization (1.0 µs),
2. processing (0.2 µs) – transmission (2.7 µs) – processing (0.2 µs),
3. decision (1.0 µs),
4. processing (0.2 µs) – transmission (2.7 µs) – processing (0.2 µs),
5. actuator (1.0 µs).

In the model described, the total delay amounts to approximately 11 µs. If data preparation and cryptographic operations take about 1 µs, they already account for a significant portion of the time budget. This can be critical, for instance, in power electronics and converters, RF/DSP control, ultrasonic sensing, protection and switching functions, or certain optical and telecommunication systems. However, these are not the only examples; the same principle applies wherever there is a fixed time budget and cryptographic protection consumes a significant share of it.
Importantly, in such a situation, the choice between hardware and software may not be the primary issue. If the entire system is too slow, merely optimizing the cryptographic operation might not solve the problem. The entire timing chain must be evaluated.

Determinism and the time budget

For systems dealing with very fast or rapidly changing processes, determinism also becomes significant. It is not merely a question of whether a cryptographic mechanism completes an operation sufficiently fast on average, but whether it can be assumed with sufficient certainty that it will complete it within the required time interval. Each additional step between obtaining information and the system's reaction introduces its own latency and potentially jitter—that is, temporal uncertainty. Overall response time can be simplified as the sum of latencies associated with sensing, preprocessing, cryptographic operations, communication, synchronization, decision logic, and physical reaction.
For time-critical systems, a mechanism with predictable and bounded latency may therefore be preferable to a solution offering higher average performance but significantly variable response times. This marks a key distinction between a standard information system and a control system. In a standard system, a few milliseconds of additional latency might be negligible. In a process with a very short time horizon, however, the same latency could render the information useless before it is even verified.
Thus, cryptographic protection can simultaneously enhance security—in terms of confidentiality and integrity—and consume a portion of the system's time budget. This is not an argument against cryptography; rather, it is a reason to evaluate it as an integral part of the entire system.

The Temporal Value of Information

This issue is also related to classification. The value of information is not necessarily constant over time. Certain information holds high value only before or during a specific event. Others may hold long-term value for analysis, planning, or reverse-engineering system characteristics.
A single data point may become practically insignificant after a certain time, but a large volume of similar data can enable the retrospective derivation of process characteristics, measurement accuracy, response times, design features, or other system parameters. Consequently, the temporal degradation of information value is not necessarily monotonic. Immediate value may drop sharply, while analytical or evidentiary value may persist. Therefore, when assessing protection needs, it is appropriate to consider:

• the time window during which the information is sensitive,
• the rate at which its value changes,
• the possibility of retrospective reconstruction,
• the potential for combination with other sources,
• requirements for long-term confidentiality or evidentiary value.

This gives rise to the concept of an information time budget. If we designate the moment of information creation as t₀ and the latest moment by which effective action can be taken based on it as t_D, then the available time budget can be approximately expressed as:
T_D = t_D - t₀

This interval must accommodate not only the cryptographic operation but the entire processing and response chain. In practice, therefore, the following condition is insufficient:
T_(crypto) < T_D; it is more important to ensure T_(end-to-end) < T_D;
at the same time, it is advisable to leave a margin for jitter, packet loss, retransmissions, load fluctuations, and other unforeseen conditions.
If this condition is not met, the cryptographic mechanism—even if technically implemented correctly—may fail to provide practical protection for the required operation, because the protected information becomes available only after the point when it can effectively be used. In such cases, the entire system architecture must be evaluated: whether certain calculations can be performed in advance, whether operations can be parallelized, whether the time-critical data path can be separated from less critical logging, or whether a different cryptographic context with lower overhead can be used.

Conclusion

Therefore, it is not appropriate to evaluate cryptography solely based on the number of bits processed per second. Latency, latency variance, determinism, and overall end-to-end response time are equally important for system design. Hardware can offer high and predictable throughput, but at the cost of greater specialization or more difficult to update. Software offers greater flexibility, but its latency can be affected by other system layers. Moreover, in practice, hybrid solutions often emerge, meaning the boundary between the two approaches is not sharply defined.
Therefore, the decisive factor is not whether hardware or software is generally faster. What matters is whether a specific architecture meets the application's timing constraints at the required security level while simultaneously providing sufficient headroom for both normal and exceptional operating conditions. As with classification, the temporal dimension of the information must be taken into account. Information may be critical only for a short period, yet it may also possess long-term analytical or evidentiary value. Consequently, cryptographic protection requirements should not be determined solely by data volume or immediate sensitivity, but also by when the information requires protection, how long that protection must last, and when the information must remain usable.
This shifts the focus from the performance of cryptographic operations themselves to the roles and functions of the various components within the cryptographic infrastructure. Other part of the series will therefore focus on the roles used and their relationship to key management material.

Autor článku:

Jan Dušátko

Jan Dušátko has been working with computers and computer security for almost a quarter of a century. In the field of cryptography, he has cooperated with leading experts such as Vlastimil Klíma or Tomáš Rosa. Currently he works as a security consultant, his main focus is on topics related to cryptography, security, e-mail communication and Linux systems.