A scratch notebook for thinking about PQC acceleration
The post-quantum standards are settled enough that the conversation has moved on from "which scheme?" to "how do we make them fast on the silicon we already have?" That's a less glamorous question and most of its answers are unsatisfying. The Kyber and Dilithium reference implementations are written in clean portable C; the actually-fast versions are AVX-2 and AVX-512 intrinsics, NEON for ARM, and a long tail of clever Barrett-reduction tricks for the modular arithmetic. Everyone benchmarks differently. Nobody benchmarks against the workload that I care about — long-lived TLS handshakes on a banking platform, with batched key generation and signature verification under steady load.
pqc-accelerate is the notebook where I work through this for myself. It's deliberately a scratchpad, not a product. The point is the exercise of staring at the cycle counts long enough to know what's worth optimizing.
The questions the notebook walks through:
- For a server doing N TLS handshakes per second with Kyber-768, where is the time going? Key generation? Decapsulation? Both? How much is in NTT and how much is in everything else?
- The NTT cost in Kyber is roughly fixed-cost. The everything-else is roughly variable. The crossover where AVX-512 stops paying for itself is somewhere in the load curve — find it.
- Dilithium signature verification has a wildly different cycle-cost profile than signing. For batch verification at scale, what's the order of operations that minimizes total latency?
- The published benchmarks are mostly for desktop-class CPUs. The deployed hardware is often a step or two older. The penalty for missing the latest vector ISA can be a 3× difference in throughput.
Nothing in this notebook is novel. The constructions it benchmarks all exist in the reference and optimized implementations. The notebook's purpose is internalization — I want to be the kind of engineer who, when someone asks "can we afford to put Kyber on this load balancer," answers from numbers I derived myself, not from a paper's abstract.
The era for these constructions is just beginning. Once they ship into ordinary cryptographic libraries (OpenSSL 3.x already has stubs), every operations team is going to face the question of how much do they cost on my fleet? The answer they get from a vendor benchmark is wrong by a factor of two in either direction depending on what the vendor wanted to sell them. The answer they get from running it themselves is the actual answer.
This is the scratchpad for getting good at deriving that answer.
What becomes possible: I know what to look for when I read a new PQC benchmark paper, and I know what to actually measure when I deploy the constructions to production.