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

[Simo Sorce <simo@redhat.com>]

On Mon, 2026-05-04 at 14:12 -0400, Jeff Barnes wrote:
> 
> 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.

The integrity mechanism is not build to detect adversarial tampering
(at least at level 1), that is not its purpose.

That said a HMAC is just a hash with a secret key in the mix, it does
not change the conditions wrt Hash if the key is known.

 
> > 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.

Of course it requires validating the library, validating the
cryptography implementation is what FIPS is for. libcrypto.so can never
be outside the boundary, unless you turn it off at runtime ...

The problems are rather that libcrypto is not instrumented to enforce
KAT tests are executed before it allows operation (crypto-API did this
via test manager) and does not provide an indicator (or blocks)
unapproved algorithms ...

Simo.

-- 
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc