Measure OpenSSL Algorithm Throughput Without Misreading the Result

You will finish with a repeatable, focused benchmark for an OpenSSL algorithm, an EVP comparison, and output that a script can collect without scraping a table. This guide uses the openssl speed subcommand from the installed OpenSSL 3.6.1 binary. The local openssl-speed(1ssl) manpage is labelled OpenSSL 3.0.13, so the command and its output may differ from the manpage on another installation.

Allow 10 to 15 minutes for a useful first pass. You need the openssl package and a shell. Run the examples as an ordinary user. A benchmark should not need sudo; elevated privileges can change scheduling and make the comparison less representative.

1. Check the binary you are about to measure

Start by recording the executable and library version. This matters because OpenSSL, its providers, compiler options, CPU features and operating-system load all affect the result.

$ command -v openssl
$ openssl version -a

On the machine used for this guide, the relevant line is:

OpenSSL 3.6.1 27 Jan 2026

Checkpoint: keep this version information beside any result you intend to compare later. A number without the tested version and host details is not a portable performance claim.

2. Run one short, focused test

Pass an algorithm name to avoid the command's default selection of a large pre-compiled set. Use one second while checking the command and a longer duration for a steadier measurement.

$ openssl speed -seconds 1 sha256
Doing sha256 ops for 1s on 16 size blocks: 1695077 sha256 ops in 0.95s
...
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
sha256           28548.67k    80038.92k   176060.16k   255326.04k   277022.00k   285559.47k

The exact figures will move with CPU frequency, thermal limits, background work and the OpenSSL build. The columns are buffer sizes, not different SHA-256 algorithms. The displayed throughput is in thousands of bytes per second. For a less noisy run, try -seconds 10 or longer, then repeat the same command several times.

Do not run the command without an algorithm merely because it is convenient. With no algorithm argument, the manpage says that a broad pre-compiled selection is tested. That can take much longer and produces more output than a focused check.

3. Compare the EVP path deliberately

OpenSSL's EVP interface is the general interface used by applications to fetch digest and cipher implementations. Benchmark it explicitly when that is the path your application uses:

$ openssl speed -seconds 1 -evp sha256
Doing sha256 ops for 1s on 16 size blocks: 1868860 sha256 ops in 0.99s
...
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
sha256           30203.80k    81776.46k   182195.72k   251212.02k   288755.59k   286819.30k

These figures are an example from one run, not a promise that EVP will always be faster or slower. The important comparison is that both tests use the same host, duration, algorithm spelling and load conditions. If you are unsure which names are available to -evp, ask OpenSSL rather than guessing:

$ openssl list -digest-algorithms
$ openssl list -cipher-algorithms

The local manpage specifically recommends those listings for EVP algorithm names. An algorithm shown by a listing is not automatically a suitable choice for your protocol; use the name your application and provider configuration actually select.

4. Make the timing choice explicit

By default, the reported operations or bytes per second use CPU user time as the divisor. Add -elapsed when wall-clock time is the measurement you need, such as when hardware engines or other asynchronous work are involved:

$ openssl speed -seconds 10 -elapsed -evp sha256

Do not mix elapsed-time and CPU-time results in one table. Record the option with each result. Also record whether the machine was idle, power-limited, pinned to a CPU or running other work. Those details often explain a change that has nothing to do with the algorithm.

For a controlled buffer-size experiment, use -bytes:

$ openssl speed -seconds 5 -bytes 4096 -evp sha256

The option affects ciphers, digests and the CSPRNG. The manpage limits the value to INT_MAX - 64 bytes, so do not use an enormous value as a casual stress test. Large buffers consume memory and can make the test about allocation or system pressure rather than the cryptographic operation.

5. Capture output for a script

Use -mr when another program needs the result. It emits tagged records instead of the human-oriented table:

$ openssl speed -seconds 1 -mr sha256
+DT:sha256:1:16
+R:1854051:sha256:0.970000
+DT:sha256:1:64
...
+H:16:64:256:1024:8192:16384
+F:6:sha256:30582284.54:78290682.83:177999127.27:252877317.17:304254189.90:287014912.00

The output above is abbreviated only to keep the example readable. Treat the format as data from the exact OpenSSL version you tested. Store the complete standard output, the command line and the exit status. Do not parse the pretty table if a machine-readable mode is available.

For a simple shell check, preserve the status immediately:

if openssl speed -seconds 5 -mr sha256 > sha256-speed.txt; then
    printf '%s\n' 'benchmark completed'
else
    status=$?
    printf 'openssl speed failed with status %s\n' "$status" >&2
    exit "$status"
fi

This writes a new result file in the current directory and does not require privilege. Choose the filename before running the test. Redirection with > truncates an existing file; use >> only when you intentionally want to append, and include the command and version in a separate record so runs cannot be confused.

6. Keep special modes inside their boundaries

The options for HMAC, CMAC, AEAD, decryption, multi-buffer operation, parallel workers and asynchronous jobs measure specific paths. For example:

$ openssl speed -seconds 5 -hmac sha256
$ openssl speed -seconds 5 -cmac aes128
$ openssl speed -seconds 5 -evp aes-128-gcm -aead

Use -decrypt only with EVP testing when you need decryption rather than encryption. Use -multi when you want several operations in parallel, and describe the worker count in your report. A parallel throughput result answers a different question from a single-operation latency result.

The manpage lists -engine, but also marks it deprecated in OpenSSL 3.0. Prefer the provider options that match your deployment, and test the provider selection separately before attributing a performance change to an algorithm. Loading a provider or writing random state can alter files or configuration, so do not add -provider, -provider-path, -rand or -writerand to a benchmark copied from elsewhere without checking what they load or overwrite.

7. Diagnose a result that looks wrong

If OpenSSL rejects an algorithm, first inspect the available names with openssl list. Do not silently substitute a similarly named digest or cipher. If throughput changes sharply between runs, repeat the same command, check CPU frequency and background load, and compare the version output. -elapsed can expose waiting that CPU-time measurement hides, but it does not make two different test setups equivalent.

If a public-key algorithm is absent from the positional list, that is expected to have limits. The manpage says positional algorithms are selected from a pre-compiled subset, and that third-party provider public-key algorithms cannot be tested by this command. EVP is intended for additional digest and cipher algorithms, not as a universal escape hatch for every public-key implementation.

There is no state to undo in the benchmark commands above. If you used output redirection, recovery is limited to restoring the previous result file from your normal backup. If you supplied -writerand, inspect the named file and its permissions before replacing or removing it. Deleting random-state data is not part of a normal speed test.