Performance Benchmarks

Performance Benchmarks

Authoritative source: BENCHMARKS.md (generated locally by running python benchmark_suite.py; not checked into version control) is the authoritative Python-API benchmark document. benchmark-results.json / benchmark-report.md (generated by python benchmarks/benchmark_runner.py) anchor the CI regression gate. build/bin/benchmark_c_raw --json reports raw C throughput without any ctypes overhead. The tables on this wiki page are a snapshot refreshed alongside the repository; they will shift by ±20 % on a different host.

Benchmark results for AMA Cryptography on Linux x86-64. All measurements use the native C library via Python/ctypes unless noted.

Platform: Linux x86-64 | CPU: 16 logical cores (AVX-512F/BW/DQ/VL/VBMI + VAES + VPCLMULQDQ) | Python: 3.11.15 Date: 2026-04-25 | ML-DSA-65 Backend: native C (no OpenSSL, no liboqs)

---

Summary Dashboard

Operation	Mean (ms)	Ops/sec
SHA3-256 (32 B)	0.001	1,002,079
HMAC-SHA3-256 auth (32 B)	0.004	231,090
HMAC-SHA3-256 verify (32 B)	0.005	183,619
HKDF-SHA3-256 (96 B output)	0.059	16,898
Ed25519 keygen	0.030	33,073
Ed25519 sign (240 B)	0.020	50,805
Ed25519 verify (240 B)	0.049	20,559
ML-DSA-65 keygen	0.280	3,574
ML-DSA-65 sign	0.338	2,958
ML-DSA-65 verify	0.137	7,309
KMS generation	0.425	2,353
Package creation (multi-layer)	0.277	3,612
Package verification	0.230	4,348

(Output of python benchmark_suite.py — all numbers Python/ctypes path on the measurement host. See the notes below for the difference between these figures and the CI-regression-suite baseline.)

---

Key Generation

Operation	Mean (ms)	Median (ms)	Std Dev (ms)	Ops/sec	Iterations
master_secret	0.0049	0.0043	0.0028	202,241	10,000
hkdf_derivation	0.0592	0.0535	0.0156	16,898	1,000
ed25519_keygen	0.0302	0.0285	0.0123	33,073	1,000
dilithium_keygen	0.2798	0.2755	0.0255	3,574	100
kms_generation	0.4250	0.4011	0.0743	2,353	100

---

Cryptographic Operations

Operation	Mean (ms)	Median (ms)	Std Dev (ms)	Ops/sec	Iterations
sha3_256	0.0010	0.0009	0.0004	1,002,079	10,000
hmac_auth	0.0043	0.0040	0.0015	231,090	10,000
hmac_verify	0.0054	0.0049	0.0015	183,619	10,000
ed25519_sign	0.0197	0.0172	0.0044	50,805	1,000
ed25519_verify	0.0486	0.0446	0.0086	20,559	1,000
dilithium_sign	0.3381	0.3345	0.0178	2,958	100
dilithium_verify	0.1368	0.1341	0.0146	7,309	100

---

Package Operations (Multi-Layer)

Operation	Mean (ms)	Median (ms)	Std Dev (ms)	Ops/sec	Iterations
canonical_encoding	0.0015	0.0014	0.0006	657,855	10,000
code_hash	0.0154	0.0140	0.0038	65,012	10,000
package_creation	0.2769	0.2659	0.0975	3,612	100
package_verification	0.2300	0.2247	0.0279	4,348	100

---

Ethical Integration Overhead

Operation	Mean (ms)	Ops/sec
ethical_context	0.0046	218,867
hkdf_standard	0.0079	126,715
hkdf_with_ethical	0.0218	45,951

Ethical context overhead: 0.0139 ms ≈ 13.9 µs wall-time (≈ 2.8× standard-HKDF latency), i.e., well under a millisecond. Negligible per-operation cost at the throughputs listed above (45,951 ops/sec).

---

Scalability (Package Creation by Input Size)

Input Scale	Mean (ms)	Ops/sec	Iterations
1x baseline	0.3865	2,587	50
10x	0.5393	1,854	50
100x	2.9212	342	50
1000x	94.7441	11	50

---

Performance Notes

Cython Acceleration

When built with Cython (python setup.py build_ext --inplace), mathematical operations in the 3R monitoring engine (Lyapunov stability, helical computations, NTT polynomial operations) show:

• 18–37x speedup over the pure Python mathematical baseline
• NumPy-integrated batch operations

Cython acceleration does not affect C-implemented cryptographic primitives (they are already native). The speedup comparison baseline is pure Python loops — not the native C library.

Algorithm Comparison

Algorithm	Sign (ms)	Verify (ms)	Sig Size
Ed25519	0.09	0.14	64 bytes
ML-DSA-65	0.53	0.15	3,309 bytes
Hybrid (Ed25519 + ML-DSA-65)	~0.62	~0.29	3,373 bytes
SPHINCS+-SHA2-256f	~230	~5.90	49,856 bytes

ML-DSA-65 is ~6× slower to sign than Ed25519 on this host (pre-SIMD scalar NTT path) but provides NIST category III quantum security. Sign/verify latency shifts substantially with CPU microarchitecture — re-run benchmark_suite.py on your deployment host before quoting numbers externally.

X25519 Field-Path Selection (3.0.0)

The X25519 Montgomery ladder now picks its field-arithmetic representation deterministically at compile time:

Toolchain / target	Path	Layout
x86-64 GCC/Clang + __int128	fe64	radix 2^64, 4 limbs of uint64_t
Other 64-bit GCC/Clang + __int128 (aarch64, ppc64le, …)	fe51	radix 2^51, 5 limbs
MSVC, clang-cl, 32-bit, no __int128	gf16	radix 2^16, 16 limbs of int64_t

Verify which path the local build picked:

./build/bin/test_x25519_path

The two __int128 paths are byte-for-byte arithmetic equivalent — see tests/c/test_x25519_field_equiv.c, which runs 1024 random (scalar, point) vectors through both ladders and asserts every output matches.

On a Sapphire Rapids canonical-host run with benchmark_c_raw, the previous pure-C fe64 path measured ~11,500 X25519 DH ops/sec vs ~21,800 for fe51 on the same hardware (Linux, GCC 12, -O3 -march=native). The radix-2^64 schoolbook trails the radix-2^51 carry-pipelined layout in pure C because GCC does not yet generate MULX+ADCX (BMI2+ADX) for the 4×4 schoolbook pattern.

X25519 fe64 MULX+ADX kernel (3.0.0, PR D)

When CPUID reports both BMI2 (CPUID.(EAX=7,ECX=0):EBX[8]) and ADX (EBX[19]), the dispatcher promotes the inner ladder's multiply / square to the in-house MULX+ADCX/ADOX kernel in src/c/internal/ama_x25519_fe64_mulx.c, compiled with per-file -mbmi2 -madx -O3 flags. Bundle gate: ama_cpuid_has_x25519_mulx() (defensive: gates each bit explicitly even though every shipped Intel Broadwell+ / AMD Zen+ part has both).

Same canonical-host class with the kernel active, this build's benchmark sandbox measures ~13,168 X25519 DH ops/sec via the Python C-FFI runner (or ~13,988 ops/sec when the C-raw harness amortises the FFI layer away) — a real ~21 % improvement over the pure-C fe64 baseline. Byte-equivalence to pure-C fe64 asserted across 4096 / 4096 random vectors by tests/c/test_x25519_fe64_mulx_equiv.c (skips with code 77 on hosts whose CPUID lacks the bundle).

The kernel is implemented as GCC/Clang inline assembly with explicit mulx (BMI2) plus adcx / adox (ADX) instructions — not via _mulx_u64 + _addcarry_u64 intrinsics. The inline-asm path exists specifically because GCC's _addcarry_u64 did not lower to ADCX/ADOX even under -madx; without the explicit mnemonic the kernel's lo-column and hi-column carry chains would serialise through a single adc chain instead of running in parallel. The kernel also ships a dedicated squaring path that exploits the off-diagonal symmetry of (sum f_i)^2 (10 multiplications: 6 cross products doubled + 4 diagonal squares — vs 16 for the full schoolbook). The active kernel is therefore already a hand-written inline-asm path using BMI2 MULX plus explicit ADX ADCX / ADOX carry-chain interleave behind the same CPUID gate. The remaining gap to the ~25K ops/sec reported by OpenSSL's hand-tuned crypto/ec/asm/x25519-x86_64.pl on the same microarchitecture class therefore reflects broader implementation differences (instruction scheduling, register allocation, reduction shape, and surrounding glue), not reliance on compiler-lowered intrinsics or the absence of a hand-written asm kernel. fe51 remains available as a fallback by building with -DAMA_X25519_FORCE_FE51; the pure-C fe64 schoolbook still runs on hosts whose CPUID lacks BMI2 + ADX (e.g. KVM guest with the bits masked, pre-Broadwell host, or any MSVC build — the kernel TU is GCC/Clang only).

3R Monitoring Overhead

• Monitoring overhead: < 2% on typical workloads
• Anomaly detection runs asynchronously in the background
• FFT computations use NumPy for batch processing when available

---

Reproducing Benchmarks

# Install dependencies
pip install -e ".[dev,monitoring]"

# Build native library
cmake -B build -DAMA_USE_NATIVE_PQC=ON -DCMAKE_BUILD_TYPE=Release
cmake --build build

# Run benchmark suite
python3 benchmark_suite.py

# Or run the regression runner
python3 benchmarks/benchmark_runner.py -v

Results are saved to benchmark_results.json, BENCHMARKS.md, and benchmarks/regression_results.json.

---

* HMAC-SHA3-256 uses the Cython binding when built (python setup.py build_ext --inplace) — zero marshaling overhead calling native C ama_hmac_sha3_256. Falls back to ctypes when the extension is absent.

Why HMAC numbers look different across paths. Three measurement paths produce three different figures for the same primitive:

• Cython microbenchmark on a 32 B message: ~250k ops/sec on this host (benchmark_suite.py "hmac_auth" column above).
• Pure ctypes on a 1 KB message: ~130k ops/sec (benchmarks/benchmark_runner.py → benchmark-results.json, baseline 76,215).
• Shared GitHub Actions runner under CI: ~12k ops/sec (much slower, noisier hardware). The benchmarks/baseline.json value is set for the CI host and is not a statement about the primitive's performance in general.

All three are measurements of ama_hmac_sha3_256. The right number to quote depends on which environment the reader cares about; cite the measurement command alongside the number.

---

Regression Baselines (from benchmarks/baseline.json)

Benchmark	Baseline (ops/sec)	Tolerance	Tier
Ama Sha3 256 Hash	113,388	±35%	microbenchmark
Hmac Sha3 256	76,215	±40%	microbenchmark
Ed25519 Keygen	10,560	±35%	microbenchmark
Ed25519 Sign	10,430	±35%	microbenchmark
Ed25519 Verify	5,113	±35%	microbenchmark
Hkdf Derive	53,193	±35%	microbenchmark
Full Package Create	746	±50%	complex_operation
Full Package Verify	2,044	±50%	complex_operation
Dilithium Keygen (optional)	1,943	±40%	microbenchmark
Dilithium Sign (optional)	1,918	±40%	microbenchmark
Dilithium Verify (optional)	4,303	±40%	microbenchmark
Kyber Keygen (optional)	2,200	±40%	microbenchmark
Kyber Encapsulate (optional)	2,400	±40%	microbenchmark
Aes 256 Gcm Encrypt (optional)	150,000	±40%	microbenchmark
Chacha20Poly1305 Encrypt (optional)	130,000	±40%	microbenchmark
X25519 Scalarmult (optional)	25,000	±40%	microbenchmark

See Cryptography Algorithms for algorithm key sizes, or Architecture for the multi-language performance architecture.

---

Standards Compliance Note

This library implements algorithms specified in FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA), and FIPS 202 (SHA-3). This implementation has NOT been submitted for CMVP validation and is NOT FIPS 140-3 certified. See CSRC_STANDARDS.md for detailed compliance status.