Inspect Linux Kernel Crypto Providers through /proc/crypto

Before you blame an application for picking the wrong cipher, check /proc/crypto to see what the kernel actually registered. This is a read-only way to inspect the ciphers exposed by the running kernel, count the advertised providers, and compare one record without treating the file as a security policy. Allow about ten minutes. You need a shell and access to /proc; none of the examples need elevated privileges.

The installed reference is proc_crypto(5) from Linux man-pages 6.7, supplied by the local manpages package. It describes /proc/crypto as a list of ciphers provided by the kernel crypto API. The file is generated by the running kernel, so its contents, ordering and available algorithms are host-specific.

1. Read the local contract

Start with the manpage that belongs to this machine's installed documentation:

$ man 5 proc_crypto
$ dpkg-query -W -f='${Package} ${Version}\n' manpages
manpages 6.7-2

The manpage gives this interface no options, configuration file or command to run: the interface is the file itself. It also points to the Linux Kernel Crypto API documentation in the kernel source tree. That boundary matters: reading the inventory is not the same as enabling an algorithm, selecting a driver, or changing a disk-encryption configuration.

2. Capture a sample without changing state

Print the first two records exactly as the running kernel exposes them:

$ awk 'BEGIN { RS="" } NR <= 2 { print }' /proc/crypto
name         : __ecb(twofish)
driver       : cryptd(__ecb-twofish-avx)
module       : cryptd
priority     : 450
selftest     : passed
internal     : yes
type         : skcipher
async        : yes
blocksize    : 16
min keysize  : 16
max keysize  : 32
ivsize       : 0
chunksize    : 16
walksize     : 16
statesize    : 0

name         : xts(twofish)
driver       : xts(ecb-twofish-avx)
module       : kernel
priority     : 400
selftest     : passed
internal     : no
type         : skcipher

Your output won't necessarily match this sample. A blank line separates records on the current system, and each record has labelled lines such as name, driver, module, priority, selftest, internal and type. The manpage defines the file's purpose but not a stable application-facing schema for every label. Treat labels and values as observations, not a promise every future kernel prints the same set.

3. Count the records before comparing them

Count provider records by their name lines. This is a quick sanity check and avoids counting individual fields as algorithms:

$ awk -F: '$1 == "name         " { count++ } END { print count " crypto records" }' /proc/crypto
130 crypto records

The number here is an example from this host and will change as the kernel, modules or hardware-backed providers change. If the command prints zero, inspect the file directly before drawing a conclusion: an empty or inaccessible proc filesystem can explain a missing inventory without meaning the kernel has no cryptographic implementation.

For a less brittle display, show only the record names:

$ awk -F: '$1 == "name         " { sub(/^ +/, "", $2); print $2 }' /proc/crypto
__ecb(twofish)
xts(twofish)
...

4. Inspect one provider and retain its context

Do not search for a name and then discard the surrounding record. Keep the complete block so the driver, module and other observed fields stay attached to it:

provider='xts(twofish)'
awk -v wanted="$provider" '
    BEGIN { RS="" }
    index($0, "name         : " wanted "\n") == 1 { print }
' /proc/crypto

Quote the shell variable even when it currently contains no spaces. If the result is empty, either the exact name isn't in the current inventory, or the record's formatting differs from this simple match. Check the names again rather than substituting a similar-looking provider.

$ uname -r
$ date -u +%FT%TZ
$ sha256sum /proc/crypto
<hash of the current proc snapshot>  /proc/crypto

A hash isn't a dependable comparison method here: the file can change as modules register, and an identical hash doesn't tell you which records differ from a previous capture. Save a deliberate text capture instead if you need an audit trail, and handle that capture as potentially sensitive operational information.

5. Use the inventory for the right decision

/proc/crypto is useful evidence when diagnosing which kernel crypto providers are registered. It is not a recommendation list and doesn't tell an application which algorithm is safe for a particular protocol. A record also doesn't prove that a user-space library, filesystem, VPN, disk-encryption tool or application will actually select it.