Benchmark Ciphers and PBKDFs with cryptsetup benchmark

You are choosing LUKS settings and want real numbers for your CPU, without risking a disk. cryptsetup benchmark measures a cipher and a password-based key derivation function (PBKDF) in memory only. You will capture the result and avoid mistaking it for a storage benchmark. The examples match cryptsetup 2.7.0 installed on this machine.

• Time: about ten minutes.
• You need: a shell and the cryptsetup-bin package.
• What it touches: kernel crypto interfaces, memory and CPU. It does not format, open, overwrite or detach a device.
• Privileges: run as an ordinary user first. Elevated privileges are not normally required.

1. Confirm the installed command

Check the binary and version before comparing results. 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. To see the local compiled-in defaults, ask for help:

$ cryptsetup benchmark --help

The action is written cryptsetup benchmark, although the manual page is named cryptsetup-benchmark. It is not a benchmark of 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. Check three things: the command exits successfully, it names the requested algorithm, and it reports both encryption and decryption rates.

$ 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 the requested specification or key size is not available through the kernel userspace crypto API. Read the command's diagnostic and inspect /proc/crypto before changing the test.

3. Measure PBKDF2 with an explicit hash

PBKDF testing is separate from the cipher test. Select the PBKDF and hash explicitly, and use a short iteration time while experimenting. Here, 100 milliseconds keeps 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 not a recommendation for a LUKS format. It is this machine's result for the requested parameters.

If you omit --pbkdf but give --hash, the installed command also performs a PBKDF2 test. Spelling out both makes scripts and reviews clearer.

• Skip the Argon2 costs. Do not use --pbkdf-memory or --pbkdf-parallel with PBKDF2. Those apply to Argon2i and Argon2id.
• Zero is not "no work". --iter-time is in milliseconds, and 0 selects the compiled-in default.

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 drops when fewer CPUs are online. Read the actual values in the result, not only the command line you typed.

Argon2 uses CPU cost, memory cost and parallel cost together, and raising memory normally raises time as well. A large value can make opening the volume slow or exhaust memory on a small system. That is a security and availability boundary, not a reason to maximise every number.

5. Keep the result in context

The benchmark uses memory only and performs no storage I/O. It can compare cipher or KDF choices on one host. 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 volume with a workload that resembles the real one, and keep that separate from this safe benchmark.

Do not assume the fastest cipher is the best deployment choice. Also weigh:

• Cipher and mode. The specification you are actually creating.
• Key size and kernel support. Availability on the target system.
• Hardware acceleration. And the requirements of the format.
• PBKDF costs. Record the algorithm and every relevant cost, or the result is hard 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 #. The manual recommends attaching the failed command's 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.