← blog

Benchmarking RustHSM vs SoftHSMv2

Criterion numbers across RSA, ECDSA, AES-GCM, ML-DSA, and ML-KEM. Where the backend choice matters, and where it doesn't.

by Victor Bobrovskiy

Micro-benchmarks lie. Production workloads lie too, but in different ways. Here is what we measure, why, and what we tell customers to conclude from it.

The setup

Intel Xeon E-2276G, 32 GB RAM, no frequency scaling, benchmarks pinned to a single core. Criterion.rs with 100 samples per point, 5-second warmup. Single-threaded. In-process shared library, not gRPC — network latency dominates anything at the millisecond scale.

Signatures

OperationRustCrypto backendaws-lc-rs backendSoftHSMv2
Ed25519 sign43.79 μs41.12 μs58.3 μs
RSA-2048 sign1.927 ms1.864 ms2.14 ms
RSA-2048 verify81 μs9.8 μs73 μs
ECDSA P-256 verify142 μs31 μs129 μs
ML-DSA-44 sign711.9 μsn/an/a

Where the backend matters most: RSA and ECDSA verify. aws-lc-rs carries BoringSSL's optimized asm paths, which are not trivially reproducible in pure Rust. Sign latencies are already dominated by the arithmetic, not the scheduling, so the delta is small.

Symmetric

OperationRustCryptoaws-lc-rs
AES-256-GCM encrypt, 4 KB3.633 μs2.91 μs
AES-256-GCM encrypt, 64 KB49.2 μs37.4 μs
ChaCha20-Poly1305 4 KB4.12 μs3.88 μs

AES-NI is AES-NI. Both paths end up in the instruction, so the delta is driven by the per-op overhead and memory dance.

Post-quantum

ML-KEM and ML-DSA only have a RustCrypto implementation available today. Expect aws-lc-rs to catch up through 2026 as NIST finalizes the post-quantum ecosystem.

  • ML-KEM-768 encapsulate: 74.46 μs
  • ML-KEM-768 decapsulate: 82.31 μs
  • ML-DSA-65 sign: 1.412 ms
  • SLH-DSA-SHA2-128s sign: 6.8 ms (don't use this one unless you have a specific reason)

What to conclude

  1. If you verify a lot (JWT-heavy APIs, TLS fanout, certificate-heavy workloads) and need the absolute best numbers: aws-lc-rs backend.
  2. If you need reproducible-build guarantees or are targeting air-gapped environments: RustCrypto backend. Pure Rust, no system dependencies.
  3. If you are evaluating a migration away from SoftHSMv2: the performance argument is a tie-to-win, not a loss. The security argument is where the actual value comes from.

Run it yourself: cargo bench against github.com/craton-co/craton-hsm-core. If your numbers materially differ from ours, we would like to know.