How to Inspect Kernel Cryptographic Ciphers and Acceleration in Linux Using /proc/crypto

The Linux kernel features a comprehensive in-kernel Cryptographic API (Crypto API) that powers low-level security functions across the operating system. Everything from disk encryption via dm-crypt and LUKS, encrypted network tunnels (IPsec, WireGuard), kernel module signature verification, and filesystem integrity checking depends on these cryptographic primitives. Understanding which cipher implementations, hashing algorithms, and hardware acceleration drivers (such as Intel AES-NI or ARM Cryptography Extensions) are registered with the kernel is vital for security auditing and performance tuning.

Rather than requiring third-party diagnostic suites, the Linux kernel surfaces its real-time cipher registry directly through the /proc/crypto virtual filesystem node. Inspecting this interface allows system administrators and security engineers to verify whether encryption workflows are leveraging hardware offload or falling back to generic software routines. If you frequently benchmark or audit Linux network and security subsystems, you may also find our tutorials on benchmarking cryptographic performance using openssl speed and implementing Linux IPsec ESP offload for hardware crypto acceleration valuable.

Understanding the Structure of /proc/crypto

The /proc/crypto file is an ASCII text interface generated dynamically by the kernel. Each registered cipher algorithm produces a separate block containing essential operational metadata. To view the entire output in your terminal, run:

cat /proc/crypto

A typical entry looks like the following:

name         : aes
driver       : aes-aesni
module       : aesni_intel
priority     : 300
refcnt       : 2
selftest     : passed
type         : cipher
blocksize    : 16
min keysize  : 16
max keysize  : 32

Key parameters within each block indicate how the kernel treats the algorithm:

• name: The generic algorithm or cipher suite identifier (for example, aes, sha256, chacha20, or gcm(aes)).
• driver: The specific binary driver providing the algorithm. A suffix such as -aesni, -neon, or -avx2 designates hardware-optimised machine code, whereas -generic indicates pure software implementation.
• module: The kernel module supplying the driver (for instance, aesni_intel or kernel if built directly into the monolithic kernel image).
• priority: An integer value dictating selection order. When multiple drivers provide the same cipher name, the Linux kernel automatically chooses the implementation with the highest priority score.
• selftest: Confirms whether the kernel cryptographic self-test passed at boot time (typically showing passed).
• type: The architectural primitive class, including cipher (symmetric block ciphers), shash (synchronous hash functions), ahash (asynchronous hash functions), or aead (authenticated encryption with associated data).

Filtering Specific Ciphers and Hashing Algorithms

Because modern Linux kernels register hundreds of algorithmic variations, piping the output of /proc/crypto through standard command-line utilities allows for targeted analysis:

To audit all implementations registered for the standard AES cipher, execute:

grep -E "(name|driver|priority|type)" /proc/crypto | grep -A 3 -B 1 "name.*: aes$"

To list all available hashing and digest algorithms (such as SHA-256, SHA-512, and MD5), filter by the shash or ahash types:

awk '/name/{name=$3} /type.*hash/{print name, $3}' /proc/crypto | sort -u

Verifying Hardware Cryptographic Acceleration

A primary objective when auditing /proc/crypto is verifying that your CPU’s hardware acceleration instructions are active. Modern x86-64 processors supply AES-NI and CLMUL instructions, while 64-bit ARM architectures supply ARMv8 Cryptography Extensions.

First, verify whether your hardware supports these CPU flags using lscpu:

lscpu | grep -E "Flags.*(aes|sha)"

Next, confirm that the kernel has bound the hardware driver with a higher priority than the fallback generic software driver:

awk '/name.*: aes$/{getline; print $0; getline; print $0}' /proc/crypto

If you observe driver : aes-aesni with a priority of 300 alongside driver : aes-generic with a priority of 100, the kernel automatically routes all AES encryption calls through hardware acceleration without administrative intervention.

Loading Missing Kernel Cryptographic Modules

If hardware-accelerated drivers do not appear in /proc/crypto despite CPU support, the responsible kernel modules may simply not have been loaded at boot time. You can manually inspect and load available crypto modules using modprobe:

# Check for available hardware acceleration modules
find /lib/modules/$(uname -r)/kernel/arch/ -type f -name "*aes*.ko*"

# Manually load the Intel AES-NI driver
sudo modprobe aesni_intel

# Manually load generic cryptographic chaining modes if required
sudo modprobe xts
sudo modprobe cryptd

After loading the module, re-read /proc/crypto to confirm that the new driver is registered, passed its initial self-test, and assumed top priority for subsequent cryptographic operations.