Latency, measured and estimated

The short answer

Two questions in one

“Is it 42 or 62?” mixes two questions. Where does a typical signature land? And how far do the slow ones stray from it? The first depends on the machine and on everything around the signature, and for the enclave we can only estimate it today. The second is about the work itself, and that we can measure now. The answer is that the band is narrow, because every signature does the same fixed amount of work.

What we measured

Each run times one call to SigningKey::sign in RustCrypto k256 0.13.4: it hashes a 256-byte message with SHA-256, then signs it with ECDSA on the secp256k1 curve, using deterministic nonces (RFC 6979). Nothing else is inside the timer: no enclave, no vsock, no network, no policy check. We ran it 200,000 times on an Apple M2 laptop that was doing its usual work, and kept every sample.

That spike is the point. Nearly all the signatures took the same time, to within a few ticks of the laptop’s clock. The smaller bumps to the right are the same work, interrupted.

Why the band is narrow

Three things keep it tight.

• The work never changes. One hash of a fixed-size message and one signature. There’s no branch that does more work for some orders than for others.
• The library takes the same time whatever the key. k256 is designed so that operations on secret values run in constant time, to resist timing attacks; NCC Group reviewed it in 2023 (their report). A side effect we like: the time doesn’t wander with the input either.
• There’s nothing to wait for. No network, no disk, no lock, no queue.

What does wander is the machine around the code: an interrupt, another process, the scheduler moving the thread, the CPU changing speed. That is the tail in Figure 2, and it’s why the shared cloud runner, where other jobs compete for the CPU, has a longer tail than the laptop. On a dedicated core with nothing else on it, the tail should shrink. We’ll show that when we’ve measured it, not before.

Through an enclave: our estimate

A Nitro Enclave has no network. Requests reach it over vsock, a socket between the instance and its enclave, and that hop costs more than the signature does. Lutsch, Franck, El-Hindi, István and Binnig measured it for their DaMoN 2025 paper, “An Analysis of AWS Nitro Enclaves for Database Workloads”: on a c6in.8xlarge, a small request and reply took 77.4 µs at the median and 85.5 µs for 99 in 100, with a long tail at 1 in 1,000 (665.4 µs). Their raw data is in their repository. Published

So our estimate is about 120 µs for a typical signature through the enclave, and under about 150 µs for 99 in 100. Two caveats, both honest. Their benchmark wasn’t tuned for latency the way a signing path will be, with pinned cores and polling instead of sleeping, so the hop may come in lower. And their 1-in-1,000 tail means the far tail through an enclave is an open question. It’s the first thing we’ll measure.

Every run

All figures in microseconds. A 99th percentile from a single run of 50,000 rests on its slowest 500 samples, which is why the laptop’s five runs spread from 47.5 to 50.2 µs while the median never moved.

How it was measured

The timed loop is short enough to read in full:

let signing_key = SigningKey::from_bytes(&[42u8; 32].into())?;
let message = [0xABu8; 256];
for _ in 0..1_000 { let _: Signature = signing_key.sign(&message); }  // warm up

for _ in 0..n {
    let t0 = Instant::now();
    let sig: Signature = signing_key.sign(&message);  // SHA-256, then ECDSA (RFC 6979)
    samples.push(t0.elapsed().as_nanos() as u64);
    black_box(sig);
}

• The clock is Rust’s monotonic Instant; on this Mac it ticks every 41.7 ns.
• Percentiles are nearest-rank: the 99th is the sample that 99% of samples are at or below.
• The build matches the workspace’s release profile: fat LTO, one codegen unit, overflow checks on. This harness’s median matches the repo’s own benchmark to within a tenth of a microsecond.
• To repeat it, take the harness (its Cargo.toml is in the comment at the top), run cargo build --release, then sign-dist 200000 > samples.txt.

What we measure next

The full round trip from the host process into the enclave and back, on a Nitro-capable instance with pinned cores, a million samples, raw data published. We call it EXP-01. When it’s done, its numbers replace the estimate on this page, whatever they turn out to be.

If you’d like it run on your instances and your workload, that’s what a pilot is for.

A correction