Files
papers/post-quantum-securities/sections/06-performance.tex
zeekay 4a753bb639 papers: reorganize into per-paper dirs, add Antje Worring as co-author
Restructured from flat .tex/.pdf files into per-paper subdirectories.
Added Antje Worring as co-author on all papers.
Synced PDFs to pdfs/ for download site.
2026-04-18 21:50:07 -07:00

40 lines
1.3 KiB
TeX

\section{Performance}
\label{sec:perf}
%% =====================================================================
Benchmarks on Apple M4 Max (Go implementation with SIMD NTT):
\begin{table}[h]
\centering
\begin{tabular}{lrrr}
\toprule
\textbf{Algorithm} & \textbf{KeyGen} & \textbf{Sign/Encap} &
\textbf{Verify/Decap} \\
\midrule
ECDSA (secp256k1) & 0.02 ms & 0.03 ms & 0.05 ms \\
Ed25519 & 0.01 ms & 0.02 ms & 0.04 ms \\
\midrule
ML-KEM-768 & 0.04 ms & 0.05 ms & 0.04 ms \\
ML-DSA-65 & 0.10 ms & 0.35 ms & 0.12 ms \\
SLH-DSA-128f & 0.01 ms & 3.50 ms & 0.20 ms \\
\midrule
Hybrid (ECDSA + ML-DSA-65) & 0.12 ms & 0.38 ms & 0.17 ms \\
\bottomrule
\end{tabular}
\caption{Cryptographic operation latencies.}
\label{tab:latency}
\end{table}
ML-DSA verification is approximately $2.4\times$ slower than ECDSA
verification. For a blockchain that processes 4,000 transactions per
second, this adds 480 $\mu$s of verification overhead per block of
1,000 transactions---negligible compared to consensus latency.
The larger signature sizes (2,420 bytes for ML-DSA-44 vs.\ 65 bytes
for ECDSA) increase transaction data by approximately 2.3~KB. At
4,000 TPS, this is 9.2~MB/s of additional bandwidth---well within the
capacity of modern validator networks.
%% =====================================================================