Benchmark cryptsetup Ciphers and PBKDFs Without Touching a Disk

You will measure a cipher and a password-based key derivation function (PBKDF) with cryptsetup benchmark, capture the result, and avoid treating a memory-only test as a storage benchmark. The examples match cryptsetup 2.7.0 installed on this machine.

Allow about ten minutes. You need a shell and the cryptsetup-bin package. These commands read kernel crypto interfaces and use memory and CPU, but do not format, open, overwrite or detach a device. Run them as an ordinary user first. Elevated privileges are not normally required.

1. Confirm the installed command

Check the binary and version before comparing results. This matters because compiled-in defaults and available algorithms vary between installations:

$ command -v cryptsetup
/usr/sbin/cryptsetup
$ cryptsetup --version
cryptsetup 2.7.0 flags: UDEV BLKID KEYRING FIPS KERNEL_CAPI HW_OPAL

Your path and feature flags may differ. The version is the useful checkpoint. Ask for help if you need to see the local compiled-in defaults:

$ cryptsetup benchmark --help

The action is written as cryptsetup benchmark, although the manual page is named cryptsetup-benchmark. Do not confuse it with a command that benchmarks a live encrypted mapping: this action creates no mapping.

2. Run a focused cipher test

Start with one explicit cipher specification and key size. The key size is in bits and must be a multiple of 8. This example uses the common XTS specification:

$ cryptsetup benchmark --cipher aes-xts-plain64 --key-size 256
# Tests are approximate using memory only (no storage IO).
# Algorithm |       Key |      Encryption |      Decryption
    aes-xts        256b      2692.4 MiB/s      2775.3 MiB/s

Exact speeds depend on the processor, kernel and system load, so the numbers above are illustrative output from this host. The useful checks are that the command exits successfully, names the requested algorithm and reports both encryption and decryption rates.

Checkpoint: capture the result without accidentally including another command's status:

$ cryptsetup benchmark --cipher aes-xts-plain64 --key-size 256
$ status=$?
$ printf 'benchmark status: %s\n' "$status"
benchmark status: 0

A failed cipher test can mean that the requested specification or key size is not available through the kernel userspace crypto API. Check the command's diagnostic and inspect /proc/crypto before changing the test. The key size shown in /proc/crypto is in bytes, while --key-size expects bits.

3. Measure PBKDF2 with an explicit hash

PBKDF testing is separate from the cipher test. Select the PBKDF and hash explicitly, then use a short iteration time while experimenting. Here, 100 milliseconds makes the test quick and reproducible enough for a smoke check:

$ cryptsetup benchmark --pbkdf pbkdf2 --hash sha256 --iter-time 100
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha256    1648704 iterations per second for 256-bit key

The reported iteration rate is not a password-cracking guarantee and is not a recommendation for a LUKS format. It describes this machine's result for the requested parameters. If you omit --pbkdf but provide --hash, the installed command also performs a PBKDF2 test; spelling out both makes scripts and review clearer.

Do not use --pbkdf-memory or --pbkdf-parallel with PBKDF2. Those costs apply to Argon2i and Argon2id, not PBKDF2. The --iter-time value is in milliseconds, and 0 selects the compiled-in default, so do not assume that zero means no work.

4. Measure a memory-hard Argon2 setting

For Argon2, memory is specified in KiB and parallel is the number of threads. Keep the first test modest, especially on a shared machine:

$ cryptsetup benchmark --pbkdf argon2id --pbkdf-memory 65536 --pbkdf-parallel 1 --iter-time 100
# Tests are approximate using memory only (no storage IO).
argon2id      4 iterations, 65536 memory, 1 parallel threads (CPUs) for 256-bit key (requested 100 ms time)

Cryptsetup may reduce the requested memory or parallel cost. The memory value is a maximum, and parallelism is reduced when fewer online CPUs are available. Check the actual values in the result, not only the command line you typed.

Argon2 uses CPU cost, memory cost and parallel cost together. Raising memory normally raises time as well. A large value can make unlocking slow or exhaust memory on a small system. That is a security and availability boundary, not a reason to maximise every number. If you need to choose LUKS2 keyslot parameters, test on the slowest machine that must unlock the volume and record the hardware and cryptsetup version with the result.

5. Keep the result in context

The benchmark explicitly uses memory only and performs no storage I/O. It can help compare cipher or KDF choices on one host, but it cannot directly predict encrypted filesystem throughput, latency, queueing, discard behaviour or the effect of a particular storage device. For a storage claim, test a disposable test volume with a workload that resembles the real one, and keep that separate from this safe benchmark.

Do not infer that the fastest cipher is automatically the best deployment choice. Check the cipher, mode, key size, kernel support, hardware acceleration and the requirements of the format you are creating. For PBKDFs, record the algorithm and all relevant costs. A result without those inputs is difficult to reproduce.

6. Diagnose failures without changing encryption

Retry a failed command with --debug when the extra diagnostic is safe to share with your support channel. Debug lines are prefixed with #. Do not paste secrets or unrelated command history into a bug report. The manual recommends attaching the failed command output with debug enabled when reporting a problem.

Kernel crypto support is required for cipher tests. If the requested cipher is rejected, verify the spelling from /proc/crypto, check the key-size constraint, and confirm that the kernel userspace symmetric-key cipher interface is available. These checks are read-only. Do not load an unreviewed module or change boot parameters merely to make an experiment pass.

There is no undo step for the examples in this guide because they do not change persistent state. Stop a long-running test with your normal terminal interrupt if necessary. If a test has already consumed too much memory, wait for it to exit and investigate system memory pressure before trying a larger value.