Re: [PATCH 2/3] AF_ALG: Drop support for off-CPU cryptography

[Richard Weinberger]

On Sun, Jul 26, 2026 at 12:04 AM Eric Biggers <ebiggers@xxxxxxxxxx> wrote:
> > You can create a CAAM BLOB (a generated and sealed key) using the
> > trusted keys subsystem and use this BLOB
> > later in AF_ALG to perform AES with a key invisible to userspace.
> >
> > e.g.
> > kid=$(keyctl add trusted mykey "new 32 pk" @s)
> > keyctl print $kid | xxd -r -p > blob.bin
> > Then just create a caam_pkey_info in userspace and feed it into AF_ALG
> > and perform AES with it.
>
> Well, specifically AES-CBC.  That's the only one that is in the driver.

Yes.

> > So, pretty please,  if you kill AF_ALG and all this, offer some way to
> > achieve the same in userspace.
>
> If needed, "cbc(paes)" and/or "cbc-paes-caam" (whichever name it is
> being accessed as) can be allowed as a special case, as a stop-gap.

Would be great.

> This would need confirmed use of that specific algorithm with upstream,
> which we don't quite have yet.  Dominique had a confirmed use of
> "tk(cbc(aes))", but that has never existed upstream in the first place,
> so it's not something that could be allowlisted upstream.

It's "cbc(paes)".

>From one of my demo applications:

struct sockaddr_alg sa = {
       .salg_family = AF_ALG,
       .salg_type = "skcipher",
       .salg_name = "cbc(paes)",
};

> You've only mentioned that it "can" be used in this way in upstream.
> Can you confirm that it *is* used, and with an actual upstream algorithm
> name, and if so which one(s)?  And if so, would you also be able to
> share whether this is for dm-crypt or not?  We should remember that
> dm-crypt accepts keys directly and AF_ALG is not needed to use it.

Well, if you require me to point to some open source application, sorry I can't.

But no, the use cases I know about are not dm-crypt.
It's more allowing to encrypt/decrypt data in userspace without being able to
extract the key from the device. Since the key is hardware bound too,
it is device
specific and you cannot decrypt on device B what you have encrypted on A, even
if you share the BLOB.
So, it's more like a building block for a poor man's secure element.

At $dayjob we've been recommending AF_ALG because it's a standard interface.
Not like other ad-hoc horrors via sysfs or worse we've seen on some BSPs.

-- 
Thanks,
//richard