Benchmarking OpenCrypt's ML-DSA and ML-KEM against RustCrypto and liboqs

What we measured

Organizations evaluating post-quantum cryptography usually ask about performance first. The algorithms behave differently from classical ones: the keys are larger, the math is different, and so are the optimization opportunities.

Below are benchmarks of OpenCrypt's ML-DSA and ML-KEM implementations, along with the factors that determine the numbers.

Methodology

Test environment

All measurements were taken on standardized hardware to make them reproducible:

Measurement protocol

Each operation was measured as follows:

1. Warmup: 1000 iterations, discarded, to stabilize the CPU frequency.
2. Measurement: 10,000 iterations with nanosecond-precision timing.
3. Statistics: we report the median with IQR, for resistance to outliers.
4. Repetition: 5 independent runs to verify consistency.

ML-DSA results

Key generation

Key generation is usually a one-time cost, but it matters for applications that generate many ephemeral keys:

Signing

Signing is the most computationally intensive operation because of rejection sampling:

Verification

Verification is usually the most frequent operation in deployed systems:

ML-KEM results

Key generation

Encapsulation

Decapsulation

Optimization techniques

1. Vectorized number theoretic transform (NTT)

The NTT is the computational core of lattice-based cryptography. Our AVX2 implementation processes 8 coefficients at a time:

#[target_feature(enable = "avx2")]
unsafe fn ntt_butterfly_avx2(
    a: &mut [i32; 256],
    zetas: &[i32; 128]
) {
    for layer in 0..8 {
        let m = 1 << layer;
        let k = 128 >> layer;

        for i in (0..256).step_by(2 * m) {
            let zeta = _mm256_set1_epi32(zetas[m + i / (2 * m)]);

            for j in (i..i + m).step_by(8) {
                let a_vec = _mm256_loadu_si256(a[j..].as_ptr() as *const __m256i);
                let b_vec = _mm256_loadu_si256(a[j + m..].as_ptr() as *const __m256i);

                let t = montgomery_mul_avx2(b_vec, zeta);
                let sum = _mm256_add_epi32(a_vec, t);
                let diff = _mm256_sub_epi32(a_vec, t);

                _mm256_storeu_si256(a[j..].as_mut_ptr() as *mut __m256i, sum);
                _mm256_storeu_si256(a[j + m..].as_mut_ptr() as *mut __m256i, diff);
            }
        }
    }
}

2. Montgomery multiplication

We use Montgomery representation to avoid expensive division operations:

// Convert to Montgomery form once
let a_mont = to_montgomery(a);
let b_mont = to_montgomery(b);

// Multiply in Montgomery form (no division)
let c_mont = montgomery_mul(a_mont, b_mont);

// Convert back only when needed
let c = from_montgomery(c_mont);

This saves approximately 15-20% in polynomial multiplication routines.

3. Lazy reduction

Instead of reducing after every arithmetic operation, we accumulate results and reduce once:

// Traditional approach: 3 reductions
let t1 = (a * b) % q;
let t2 = (t1 + c * d) % q;
let t3 = (t2 + e * f) % q;

// Lazy reduction: 1 reduction
let sum = a * b + c * d + e * f;  // May exceed q
let result = barrett_reduce(sum);  // Single reduction

4. Cache-friendly memory access

We structure data layouts to maximize cache utilization:

// Poor cache behavior: strided access
for i in 0..256 {
    for j in 0..4 {
        result[j][i] = process(input[j][i]);
    }
}

// Optimized: sequential access
for j in 0..4 {
    for i in 0..256 {
        result[j][i] = process(input[j][i]);
    }
}

Results by platform

Performance varies significantly across platforms:

Recommendations by use case

Web servers (TLS)

For TLS key exchange with ML-KEM:

Code signing

For software signatures with ML-DSA:

IoT and embedded

For constrained environments:

Running the benchmarks yourself

To reproduce these results on your own hardware:

# Clone and build
git clone https://github.com/seceq/opencrypt
cd opencrypt

# Run comprehensive benchmarks
cargo bench --features=bench

# Run specific algorithm
cargo bench --features=bench -- ml_dsa_65

# Generate comparison report
cargo bench --features=bench -- --save-baseline current
cargo bench --features=bench -- --baseline current

The benchmarks report results both in human-readable form and as JSON for automated analysis.

Our conclusion: post-quantum cryptography is ready for production. Implemented carefully, it costs little compared with classical algorithms, and at equivalent security levels it is sometimes faster. OpenCrypt also shows that pure Rust can compete with optimized C libraries without giving up Rust's safety guarantees.