Re: [PATCH] crypto: af_alg - Document the deprecation of AF_ALG

[Jeff Barnes <jeffbarnes@linux.microsoft.com>]

On May 4 2026, at 1:39 pm, Eric Biggers <ebiggers@kernel.org> wrote:
>  
> That seems to be an implementation of FIPS 140-3's integrity self-check.
> A few observations:
>  
> - It could easily use userspace SHA-512 code instead.  If including
>  libcrypto.so in the "FIPS cryptographic boundary" would cause
>  certification difficulties, then a sha512.c file could simply be added
>  to 'libkcapi-hmaccalc' which is already in it.

Indeed expanding the crypto boundary to include libcrypto.so would cause
certification difficulties, it would mean certifying all of libcrypto.so
with the kernel. There *may* be a case for saying that it is outside the
module boundary but only if:

    * The integrity mechanism is clearly external
    * The cryptographic module refuses to operate unless integrity is confirmed
    * The trust relationship is clearly documented

I don't see how this could be justified cleanly without significant pushback.

>  
> - It's compatible with all of the proposed hardening.  It doesn't
>  require zero-copy performance.  It runs as root, so it would be
>  compatible with a capability check.  "hmac(sha512)" will need to be on
>  the algorithm allowlist anyway for iwd.
>  
> - FIPS 140-3 might also allow it to be simplified to use a plain hash
>  instead of pointlessly using HMAC with a fixed key.

FIPS 140‑3 (via ISO/IEC 19790) draws a hard distinction between:
    * Integrity checking (cryptographic protection)
    * Integrity measurement (detection only)

A plain hash provides no protection against an attacker who can modify
both the object and its reference hash.

>  
> By the way, also on the topic of FIPS 140-3, some people do use AF_ALG
> for ACVP (even though it's not all that great for that purpose, either).
> But ACVP is a testing thing, not something that is needed on production
> systems.  ACVP can just be run as root on a testing build; there's no
> need to enable support for it in the actual production build.

Agreed it's not a good use case. Unless/until pkcs1 is supported, I
don't see how you can use it for all of the test cases. Plus as
evidenced by Ubuntu's new cert, it requires validating the library.

>  
> - Eric
>