When ML-DSA latency does not make sense

An ML-DSA latency value can look surprising for a simple reason: the number may answer a different question than the one being asked.

If the question is, “How long did this ML-DSA signing operation take in this workload?” then a useful measurement needs to stay tied to one observed operation, one concrete runtime symbol, one process, and one measurement boundary. A request round trip, a TLS handshake, a key-generation step, a verification call, or several crypto operations grouped into one family are different measurements. They can all be valuable, but they cannot be compared as if they were one thing.

This article shows how to read runtime crypto latency as evidence for an engineering decision rather than a single algorithm benchmark.

Cloudflare Workers now exposes native PQC building blocks

We verified Cloudflare’s October 1, 2026 announcement, Support for modern cryptographic algorithms in Workers. It introduces opt-in post-quantum Web Crypto support in Workers for ML-KEM and ML-DSA. For signatures, Cloudflare lists ML-DSA-44, ML-DSA-65, and ML-DSA-87; developers enable the API with the webcrypto_modern_algorithms compatibility flag.

This matters because an application can now call ML-DSA through the Workers runtime instead of necessarily bundling a separate JavaScript or WebAssembly implementation. Cloudflare says the implementation is in workerd’s Web Crypto layer and is backed by BoringSSL primitives. That is a meaningful new integration option for applications that need to evaluate post-quantum signatures at the edge.

It is not a one-switch post-quantum migration. The announcement makes the same boundary clear: these APIs are building blocks for testing and integrating PQC-aware protocols and libraries. Teams still need to identify the signing path, check library compatibility, account for larger keys and signatures, and validate the behavior of their own workload. That is where operation-level runtime evidence and latency analysis become useful.

The question behind the number

ML-DSA is NIST’s post-quantum digital-signature standard, specified in FIPS 204. Its key generation, signing, and verification are distinct operations with different inputs and different costs. In a real service, those costs also sit inside a larger path that can include message preparation, serialization, scheduling, allocations, I/O, retries, and other cryptographic helpers.

That means a statement such as “ML-DSA took 2 ms” is incomplete unless it answers at least these questions:

Question	Why it changes the interpretation
Which operation ran?	Key generation, signing, and verification should not be grouped under a signing label.
Which implementation and symbol ran?	A library wrapper and its internal helper can have different timing boundaries.
Which process and workload produced it?	The same code may behave differently under a cold start, contention, or a production-like request mix.
What does the timer include?	A runtime function duration is not an end-to-end request duration.
How many samples were observed?	A single sample cannot establish a stable percentile or a regression.

The goal is not to eliminate context. It is to preserve it so a team can decide what to test next.

How a runtime crypto duration is produced

Laviq observes selected crypto functions at runtime. The agent records a monotonic timestamp at function entry and another at function return. The difference is carried as the crypto event duration. The backend retains the raw duration and derives summaries from the observed samples.

The timing boundary is precise:

1. The workload calls a known runtime symbol. The observation is about that call, not an assumed source-code path.
2. The entry probe records the start. The return probe records the end on the same thread, so the event describes the observed call interval.
3. The event carries identity with the duration. Algorithm, operation, symbol, process, library, timestamp, and duration should remain available for review.
4. Performance Lab aggregates comparable samples. Percentiles and averages are useful only after the samples are separated by the question they answer.

This evidence can establish that a selected symbol executed and how long its observed call interval lasted in that scan. It does not prove an ML-DSA benchmark result, constant-time behavior, total customer-visible latency, or performance in every environment.

Why a plausible number can still be wrong for the decision

There are several common ways a number becomes misleading without being technically false.

A family label hides operation differences

An algorithm-family label such as “ML-DSA signing” must only contain signing samples. If verification or key-generation samples share that series, its average and percentiles become a blend of different work. The label may look precise while the data answers a broader question.

The corrective check is straightforward: group the raw events by algorithm, operation, parameter_set, symbol, process identity, and library before looking at aggregate latency. If more than one operation appears, present separate series or rename the aggregate to say that it contains mixed ML-DSA activity.

The observed function is not the whole request

A runtime duration may be much smaller than the request latency because it excludes everything before entry and after return. It may also be a poor proxy for the application’s signing cost if the selected symbol is a wrapper that performs setup or dispatch.

Use two lanes when that distinction matters: one for the observed ML-DSA call and one for the enclosing request, job, or protocol window. Correlate them only when the event relationship is available; do not subtract unrelated averages and call the result crypto overhead.

Very short calls amplify observation cost

The entry and return hooks themselves take time. For a long ML-DSA operation this fixed overhead may be negligible. For a fast helper or a narrow wrapper, it can become a meaningful share of the reported interval.

The right response is a controlled comparison: run the same workload with the selected observation enabled and disabled, hold the host and workload conditions constant, and compare distributions rather than one request. That comparison measures instrumentation impact; it does not retroactively turn an uncalibrated trace into a benchmark.

A warm-up, retry, or contention event dominates a small sample set

Key loading, JIT compilation, cache state, CPU scheduling, garbage collection, and queueing can all change an observed call. A p99 calculated from a handful of samples is simply the largest observed sample under a formula, not a reliable tail-latency conclusion.

Keep the sample count next to each percentile. Preserve the timestamped events so an outlier can be inspected alongside the workload logs and host conditions.

A concrete review workflow

When a Performance Lab chart looks wrong, start from the individual events rather than the chart.

1. Select the exact scan, target, process, library, and symbol that produced the point.
2. Split the events into ML-DSA keygen, sign, and verify operations. Do not carry a generic signing label across them.
3. Check parameter set and implementation identity. ML-DSA-44, ML-DSA-65, and ML-DSA-87 are different parameter sets and should not silently share a benchmark claim.
4. Compare sample count, median, p95, p99, minimum, maximum, and timestamps within each homogeneous group.
5. Compare the observed call interval with a separately measured request or protocol interval only when both came from the same bounded workload run.
6. Reproduce an unexpected distribution with a controlled workload, documented host conditions, and an enabled-versus-disabled observation comparison.

At the end of that process, the outcome can be specific: “signing in this library and process became slower under this workload,” “the selected series mixed verification and signing,” or “we need a better timing boundary.” Each is a usable engineering result.

Watch the demo

The following demo was supplied with this article. It illustrates the Laviq runtime-evidence workflow; it should be read as a demonstration of the shown environment, not as a general ML-DSA performance claim.

If embedded playback is unavailable, use the supplied demo URL.

What to use the measurement for

Runtime timing is most useful as a decision aid. It can help a team find an active cryptographic path, identify whether an observed ML-DSA operation is on a latency-sensitive route, select a realistic workload for controlled testing, and preserve the evidence behind a migration decision.

It should not be used on its own to choose an algorithm, certify a service-level objective, or claim that an entire application is post-quantum ready. Those decisions require the surrounding workload evidence, controlled experiments, compatibility review, and the operational constraints of the deployment.

The next time an ML-DSA latency number does not make sense, treat that as a prompt to narrow the question. Bind the number to the operation, the symbol, the process, the scan, and the timer boundary. The result is a measurement that an engineer can reproduce, challenge, and use.