Re: [V1 0/4] User API for KPP

[Eric Biggers <ebiggers@kernel.org>]

On Mon, Sep 15, 2025 at 10:40:35AM +0200, Rodolfo Giometti wrote:
> This patchset adds a dedicated user interface for the Key-agreement
> Protocol Primitive (KPP).
> 
> From user applications, we can now use the following specification for
> AF_ALG sockets:
> 
>     struct sockaddr_alg sa = {
>             .salg_family = AF_ALG,
>             .salg_type = "kpp",
>             .salg_name = "ecdh-nist-p256",
>     };
> 
> Once the private key is set with ALG_SET_KEY or (preferably)
> ALG_SET_KEY_BY_KEY_SERIAL, the user program reads its public key from
> the socket and then writes the peer's public key to the socket.
> 
> The shared secret calculated by the selected kernel algorithm is then
> available for reading.
> 
> For example, if we create a trusted key like this:
> 
>     kpriv_id=$(keyctl add trusted kpriv "new 32" @u)
> 
> A simple example code is as follows:
> 
>     key_serial_t key_id;
> 
>     /* Generate the socket for KPP operation */
>     sk_fd = socket(AF_ALG, SOCK_SEQPACKET, 0);
>     bind(sk_fd, (struct sockaddr *)&sa, sizeof(sa));
> 
>     /* kpriv_id holds the trusted key ID */
>     setsockopt(sk_fd, SOL_ALG, ALG_SET_KEY_BY_KEY_SERIAL,
>                &key_id, sizeof(key_id));
> 
>     /* Get the operational socket */
>     op_fd = accept(sk_fd, NULL, 0);
> 
>     /* Read our public key */
>     recv(op_fd, pubkey, pubkey_len, 0);
> 
>     /* Write the peer's public key */
>     send(op_fd, peer_pubkey, peer_pubkey_len, 0);
> 
>     /* Read the shared secret */
>     len = recv(op_fd, secret, secret_len, 0);
> 
> Each time we write a peer's public key, we can read a different shared
> secret.
> 
> Rodolfo Giometti (4):
>   crypto ecdh.h: set key memory region as const
>   crypto kpp.h: add new method set_secret_raw in struct kpp_alg
>   crypto ecdh.c: define the ECDH set_secret_raw method
>   crypto: add user-space interface for KPP algorithms
> 
>  crypto/Kconfig        |   8 ++
>  crypto/Makefile       |   1 +
>  crypto/algif_kpp.c    | 286 ++++++++++++++++++++++++++++++++++++++++++
>  crypto/ecdh.c         |  31 +++++
>  include/crypto/ecdh.h |   2 +-
>  include/crypto/kpp.h  |  29 +++++
>  6 files changed, 356 insertions(+), 1 deletion(-)
>  create mode 100644 crypto/algif_kpp.c

First, this lacks any description of a use case.

Second, *if* this is done at all, then it must give access to hardware
drivers *only*.  We've had way too many problems with userspace software
inappropriately depending on the in-kernel software crypto code via
AF_ALG, when it should just be doing the crypto in userspace.

The asymmetric algorithms are especially bad because the in-kernel
implementations of most of them (all except Curve25519, I think) have
known timing attack vulnerabilities.  Implementing these algorithms is
really hard, and the in-kernel implementations just haven't had the same
level of care applied to them as userspace implementations.

We've seen time and time again that if a UAPI is offered, then userspace
will use it, even when it's not the appropriate solution.  Then it can't
be fixed, and everyone ends up worse off.

- Eric