Companion to the “Post-Quantum Primitive Candidates” documents for the Blend Protocol and the Bedrock Layer
Every figure quoted in this document is drawn from the published benchmark dataset, which can be explored interactively — per-algorithm latencies, the TLS 1.3 phase matrix, and cross-platform comparisons — at the dashboard: logos-blockchain.github.io/research/pqc (https://logos-blockchain.github.io/research/pqc/).
This document reports how fast the post-quantum cryptographic primitives under consideration for Logos Blockchain actually run — and how large their keys, ciphertexts, and signatures are — on four concrete machines, measured through three independent implementations. It is a companion to the two candidate documents — Post-Quantum Primitive Candidates for the Blend Protocol and Post-Quantum Primitive Candidates for the Logos Bedrock Layer: those documents argue which primitives are viable candidates for each layer and why; this one supplies the measured costs, shared by both, so the choices can be made against real numbers rather than estimates.
Four machines were measured. One of them is the reference platform; the other three are cross-platform datapoints:
The three non-Pi runs are deliberately not reference-grade (each records its own reasons — macOS offers no governor control or guaranteed pinning; the x86 build is untuned), and they are read accordingly: the Pi is the controlled baseline and the headline source of every quoted number; the other three corroborate. The tables below carry all four machines — read the Pi row as the headline figure and the other three as corroboration; beyond the tables, the M4 Pro and x86 runs are cited in the text wherever they change or sharpen a conclusion.
Three implementation stacks were measured on the primitives:
Measuring the same algorithm through independent codebases is what separates algorithm-intrinsic cost from implementation-specific cost: where two independent implementations agree, the number is a property of the algorithm; where they diverge, the gap is itself a finding — and several of the most useful results below are exactly such gaps. The TLS section applies the same logic one level up: the same handshake configurations run through three TLS stacks (OpenSSL natively, OpenSSL through the experimental oqs-provider, and rustls), so the cost of a configuration is separable from the cost of one stack’s implementation of it.
Everything below is traceable: every number comes from a self-describing result file (a JSON with the full machine, toolchain, and measurement configuration embedded), and the source files are named at the end.
How the document is organized. Each section opens with a general-picture chart, so the shape of the trade-off is visible before any table; the per-family tables that follow carry the exact figures. KEMs, signatures, implementation comparisons, and TLS each have their own section and their own charts — the different kinds of measurement are never mixed in one graphic. All charts use the Pi’s numbers.
What this document does not do. It does not recommend a primitive. In terms of the migration phases, it covers only the primitives underlying Phases 0–2 — KEMs for the TLS-level (Phase 0) and message-level (Phase 1) confidentiality migrations, and signature schemes for Phase 2 (Phase 0 and Phase 2 apply to both Blend and Bedrock; Phase 1 exists only in Blend, as Bedrock has no per-message confidentiality surface); Phase 3, the post-quantum ZK proof system, is out of scope: proof-system cost is dominated by circuit- and workload-specific factors and belongs in a dedicated evaluation. It does not measure a real Logos workload end-to-end (for example, a full Proof-of-Leadership proof); it measures the underlying primitives in isolation and, one level up, inside a TLS handshake — and, in the stress section, under sustained load on both sides of an exchange at once.
What every number in this document is. Unless stated otherwise, every reported time is a single-core, single-threaded measurement: the median wall-clock time of N repetitions of the named operation on one core, with no multi-core parallelism anywhere in the harness (the only within-core parallelism is the backend’s SIMD vectorization). For the TLS section specifically, client and server run as separate single-threaded processes on the same machine over loopback, and the reported time is the wall-clock duration of one complete handshake as observed by the client — so it includes both sides’ cryptographic and serialization work and no network delay. The one exception is the sender/receiver stress section, which is explicitly a multi-threaded, both-sides-at-once measurement and says so.