[V1 0/4] User API for KPP

[V1 0/4] User API for KPP

[Rodolfo Giometti]

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

-- 
2.34.1

[V1 1/4] crypto ecdh.h: set key memory region as const

[Rodolfo Giometti]

As in include/crypto/dh.h the memory region of a private key must be
set as constant.

Signed-off-by: Rodolfo Giometti <giometti@enneenne.com>
---
 include/crypto/ecdh.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/crypto/ecdh.h b/include/crypto/ecdh.h
index 9784ecdd2fb4..2e0fb35b929b 100644
--- a/include/crypto/ecdh.h
+++ b/include/crypto/ecdh.h
@@ -35,7 +35,7 @@
  * @key_size:	Size of the private ECDH key
  */
 struct ecdh {
-	char *key;
+	const char *key;
 	unsigned short key_size;
 };
 
-- 
2.34.1

Re: [V1 1/4] crypto ecdh.h: set key memory region as const

[kernel test robot]

Hi Rodolfo,

kernel test robot noticed the following build errors:

[auto build test ERROR on herbert-cryptodev-2.6/master]
[also build test ERROR on herbert-crypto-2.6/master linus/master v6.17-rc6 next-20250915]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Rodolfo-Giometti/crypto-ecdh-h-set-key-memory-region-as-const/20250915-164558
base:   https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
patch link:    https://lore.kernel.org/r/20250915084039.2848952-2-giometti%40enneenne.com
patch subject: [V1 1/4] crypto ecdh.h: set key memory region as const
config: riscv-randconfig-001-20250916 (https://download.01.org/0day-ci/archive/20250916/202509161457.uTdEUas6-lkp@intel.com/config)
compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project 65ad21d730d25789454d18e811f8ff5db79cb5d4)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250916/202509161457.uTdEUas6-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202509161457.uTdEUas6-lkp@intel.com/

All errors (new ones prefixed by >>):

>> drivers/crypto/hisilicon/hpre/hpre_crypto.c:1430:23: error: passing 'const char *' to parameter of type 'char *' discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers]
    1430 |         if (hpre_key_is_zero(params.key, params.key_size)) {
         |                              ^~~~~~~~~~
   drivers/crypto/hisilicon/hpre/hpre_crypto.c:1369:36: note: passing argument to parameter 'key' here
    1369 | static bool hpre_key_is_zero(char *key, unsigned short key_sz)
         |                                    ^
   1 error generated.


vim +1430 drivers/crypto/hisilicon/hpre/hpre_crypto.c

1e609f5fb73b6b1 Hui Tang   2021-05-29  1399  
05e7b906aa7c869 Meng Yu    2021-03-04  1400  static int hpre_ecdh_set_secret(struct crypto_kpp *tfm, const void *buf,
05e7b906aa7c869 Meng Yu    2021-03-04  1401  				unsigned int len)
05e7b906aa7c869 Meng Yu    2021-03-04  1402  {
05e7b906aa7c869 Meng Yu    2021-03-04  1403  	struct hpre_ctx *ctx = kpp_tfm_ctx(tfm);
b0ab0797f7ab74b Weili Qian 2023-07-07  1404  	unsigned int sz, sz_shift, curve_sz;
b94c910afda050a Hui Tang   2021-05-12  1405  	struct device *dev = ctx->dev;
1e609f5fb73b6b1 Hui Tang   2021-05-29  1406  	char key[HPRE_ECC_MAX_KSZ];
05e7b906aa7c869 Meng Yu    2021-03-04  1407  	struct ecdh params;
05e7b906aa7c869 Meng Yu    2021-03-04  1408  	int ret;
05e7b906aa7c869 Meng Yu    2021-03-04  1409  
05e7b906aa7c869 Meng Yu    2021-03-04  1410  	if (crypto_ecdh_decode_key(buf, len, &params) < 0) {
05e7b906aa7c869 Meng Yu    2021-03-04  1411  		dev_err(dev, "failed to decode ecdh key!\n");
05e7b906aa7c869 Meng Yu    2021-03-04  1412  		return -EINVAL;
05e7b906aa7c869 Meng Yu    2021-03-04  1413  	}
05e7b906aa7c869 Meng Yu    2021-03-04  1414  
1e609f5fb73b6b1 Hui Tang   2021-05-29  1415  	/* Use stdrng to generate private key */
1e609f5fb73b6b1 Hui Tang   2021-05-29  1416  	if (!params.key || !params.key_size) {
1e609f5fb73b6b1 Hui Tang   2021-05-29  1417  		params.key = key;
b0ab0797f7ab74b Weili Qian 2023-07-07  1418  		curve_sz = hpre_ecdh_get_curvesz(ctx->curve_id);
b0ab0797f7ab74b Weili Qian 2023-07-07  1419  		if (!curve_sz) {
b0ab0797f7ab74b Weili Qian 2023-07-07  1420  			dev_err(dev, "Invalid curve size!\n");
b0ab0797f7ab74b Weili Qian 2023-07-07  1421  			return -EINVAL;
b0ab0797f7ab74b Weili Qian 2023-07-07  1422  		}
b0ab0797f7ab74b Weili Qian 2023-07-07  1423  
b0ab0797f7ab74b Weili Qian 2023-07-07  1424  		params.key_size = curve_sz - 1;
1e609f5fb73b6b1 Hui Tang   2021-05-29  1425  		ret = ecdh_gen_privkey(ctx, &params);
1e609f5fb73b6b1 Hui Tang   2021-05-29  1426  		if (ret)
1e609f5fb73b6b1 Hui Tang   2021-05-29  1427  			return ret;
1e609f5fb73b6b1 Hui Tang   2021-05-29  1428  	}
1e609f5fb73b6b1 Hui Tang   2021-05-29  1429  
05e7b906aa7c869 Meng Yu    2021-03-04 @1430  	if (hpre_key_is_zero(params.key, params.key_size)) {
05e7b906aa7c869 Meng Yu    2021-03-04  1431  		dev_err(dev, "Invalid hpre key!\n");
05e7b906aa7c869 Meng Yu    2021-03-04  1432  		return -EINVAL;
05e7b906aa7c869 Meng Yu    2021-03-04  1433  	}
05e7b906aa7c869 Meng Yu    2021-03-04  1434  
05e7b906aa7c869 Meng Yu    2021-03-04  1435  	hpre_ecc_clear_ctx(ctx, false, true);
05e7b906aa7c869 Meng Yu    2021-03-04  1436  
05e7b906aa7c869 Meng Yu    2021-03-04  1437  	ret = hpre_ecdh_set_param(ctx, &params);
05e7b906aa7c869 Meng Yu    2021-03-04  1438  	if (ret < 0) {
05e7b906aa7c869 Meng Yu    2021-03-04  1439  		dev_err(dev, "failed to set hpre param, ret = %d!\n", ret);
05e7b906aa7c869 Meng Yu    2021-03-04  1440  		return ret;
05e7b906aa7c869 Meng Yu    2021-03-04  1441  	}
05e7b906aa7c869 Meng Yu    2021-03-04  1442  
05e7b906aa7c869 Meng Yu    2021-03-04  1443  	sz = ctx->key_sz;
05e7b906aa7c869 Meng Yu    2021-03-04  1444  	sz_shift = (sz << 1) + sz - params.key_size;
05e7b906aa7c869 Meng Yu    2021-03-04  1445  	memcpy(ctx->ecdh.p + sz_shift, params.key, params.key_size);
05e7b906aa7c869 Meng Yu    2021-03-04  1446  
05e7b906aa7c869 Meng Yu    2021-03-04  1447  	return 0;
05e7b906aa7c869 Meng Yu    2021-03-04  1448  }
05e7b906aa7c869 Meng Yu    2021-03-04  1449  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [V1 1/4] crypto ecdh.h: set key memory region as const

[kernel test robot]

Hi Rodolfo,

kernel test robot noticed the following build warnings:

[auto build test WARNING on herbert-cryptodev-2.6/master]
[also build test WARNING on herbert-crypto-2.6/master linus/master v6.17-rc6 next-20250916]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Rodolfo-Giometti/crypto-ecdh-h-set-key-memory-region-as-const/20250915-164558
base:   https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
patch link:    https://lore.kernel.org/r/20250915084039.2848952-2-giometti%40enneenne.com
patch subject: [V1 1/4] crypto ecdh.h: set key memory region as const
config: arm64-defconfig (https://download.01.org/0day-ci/archive/20250917/202509170134.MOV2jymf-lkp@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 15.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250917/202509170134.MOV2jymf-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202509170134.MOV2jymf-lkp@intel.com/

All warnings (new ones prefixed by >>):

   drivers/crypto/hisilicon/hpre/hpre_crypto.c: In function 'hpre_ecdh_set_secret':
>> drivers/crypto/hisilicon/hpre/hpre_crypto.c:1430:36: warning: passing argument 1 of 'hpre_key_is_zero' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
    1430 |         if (hpre_key_is_zero(params.key, params.key_size)) {
         |                              ~~~~~~^~~~
   drivers/crypto/hisilicon/hpre/hpre_crypto.c:1369:36: note: expected 'char *' but argument is of type 'const char *'
    1369 | static bool hpre_key_is_zero(char *key, unsigned short key_sz)
         |                              ~~~~~~^~~


vim +1430 drivers/crypto/hisilicon/hpre/hpre_crypto.c

1e609f5fb73b6b Hui Tang   2021-05-29  1399  
05e7b906aa7c86 Meng Yu    2021-03-04  1400  static int hpre_ecdh_set_secret(struct crypto_kpp *tfm, const void *buf,
05e7b906aa7c86 Meng Yu    2021-03-04  1401  				unsigned int len)
05e7b906aa7c86 Meng Yu    2021-03-04  1402  {
05e7b906aa7c86 Meng Yu    2021-03-04  1403  	struct hpre_ctx *ctx = kpp_tfm_ctx(tfm);
b0ab0797f7ab74 Weili Qian 2023-07-07  1404  	unsigned int sz, sz_shift, curve_sz;
b94c910afda050 Hui Tang   2021-05-12  1405  	struct device *dev = ctx->dev;
1e609f5fb73b6b Hui Tang   2021-05-29  1406  	char key[HPRE_ECC_MAX_KSZ];
05e7b906aa7c86 Meng Yu    2021-03-04  1407  	struct ecdh params;
05e7b906aa7c86 Meng Yu    2021-03-04  1408  	int ret;
05e7b906aa7c86 Meng Yu    2021-03-04  1409  
05e7b906aa7c86 Meng Yu    2021-03-04  1410  	if (crypto_ecdh_decode_key(buf, len, &params) < 0) {
05e7b906aa7c86 Meng Yu    2021-03-04  1411  		dev_err(dev, "failed to decode ecdh key!\n");
05e7b906aa7c86 Meng Yu    2021-03-04  1412  		return -EINVAL;
05e7b906aa7c86 Meng Yu    2021-03-04  1413  	}
05e7b906aa7c86 Meng Yu    2021-03-04  1414  
1e609f5fb73b6b Hui Tang   2021-05-29  1415  	/* Use stdrng to generate private key */
1e609f5fb73b6b Hui Tang   2021-05-29  1416  	if (!params.key || !params.key_size) {
1e609f5fb73b6b Hui Tang   2021-05-29  1417  		params.key = key;
b0ab0797f7ab74 Weili Qian 2023-07-07  1418  		curve_sz = hpre_ecdh_get_curvesz(ctx->curve_id);
b0ab0797f7ab74 Weili Qian 2023-07-07  1419  		if (!curve_sz) {
b0ab0797f7ab74 Weili Qian 2023-07-07  1420  			dev_err(dev, "Invalid curve size!\n");
b0ab0797f7ab74 Weili Qian 2023-07-07  1421  			return -EINVAL;
b0ab0797f7ab74 Weili Qian 2023-07-07  1422  		}
b0ab0797f7ab74 Weili Qian 2023-07-07  1423  
b0ab0797f7ab74 Weili Qian 2023-07-07  1424  		params.key_size = curve_sz - 1;
1e609f5fb73b6b Hui Tang   2021-05-29  1425  		ret = ecdh_gen_privkey(ctx, &params);
1e609f5fb73b6b Hui Tang   2021-05-29  1426  		if (ret)
1e609f5fb73b6b Hui Tang   2021-05-29  1427  			return ret;
1e609f5fb73b6b Hui Tang   2021-05-29  1428  	}
1e609f5fb73b6b Hui Tang   2021-05-29  1429  
05e7b906aa7c86 Meng Yu    2021-03-04 @1430  	if (hpre_key_is_zero(params.key, params.key_size)) {
05e7b906aa7c86 Meng Yu    2021-03-04  1431  		dev_err(dev, "Invalid hpre key!\n");
05e7b906aa7c86 Meng Yu    2021-03-04  1432  		return -EINVAL;
05e7b906aa7c86 Meng Yu    2021-03-04  1433  	}
05e7b906aa7c86 Meng Yu    2021-03-04  1434  
05e7b906aa7c86 Meng Yu    2021-03-04  1435  	hpre_ecc_clear_ctx(ctx, false, true);
05e7b906aa7c86 Meng Yu    2021-03-04  1436  
05e7b906aa7c86 Meng Yu    2021-03-04  1437  	ret = hpre_ecdh_set_param(ctx, &params);
05e7b906aa7c86 Meng Yu    2021-03-04  1438  	if (ret < 0) {
05e7b906aa7c86 Meng Yu    2021-03-04  1439  		dev_err(dev, "failed to set hpre param, ret = %d!\n", ret);
05e7b906aa7c86 Meng Yu    2021-03-04  1440  		return ret;
05e7b906aa7c86 Meng Yu    2021-03-04  1441  	}
05e7b906aa7c86 Meng Yu    2021-03-04  1442  
05e7b906aa7c86 Meng Yu    2021-03-04  1443  	sz = ctx->key_sz;
05e7b906aa7c86 Meng Yu    2021-03-04  1444  	sz_shift = (sz << 1) + sz - params.key_size;
05e7b906aa7c86 Meng Yu    2021-03-04  1445  	memcpy(ctx->ecdh.p + sz_shift, params.key, params.key_size);
05e7b906aa7c86 Meng Yu    2021-03-04  1446  
05e7b906aa7c86 Meng Yu    2021-03-04  1447  	return 0;
05e7b906aa7c86 Meng Yu    2021-03-04  1448  }
05e7b906aa7c86 Meng Yu    2021-03-04  1449  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

[V1 2/4] crypto kpp.h: add new method set_secret_raw in struct kpp_alg

[Rodolfo Giometti]

This method can be used to correctly set the private key from a binary
data buffer. This function class should encode the key and then simply
call the specific set_secret() function based on the corresponding
algorithm.

Signed-off-by: Rodolfo Giometti <giometti@enneenne.com>
---
 include/crypto/kpp.h | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/include/crypto/kpp.h b/include/crypto/kpp.h
index 2d9c4de57b69..355734cb29ee 100644
--- a/include/crypto/kpp.h
+++ b/include/crypto/kpp.h
@@ -54,6 +54,9 @@ struct crypto_kpp {
 /**
  * struct kpp_alg - generic key-agreement protocol primitives
  *
+ * @set_secret_raw:     Function invokes the protocol specific function to
+ *                      encode and set the secret private key in a raw
+ *                      binary format.
  * @set_secret:		Function invokes the protocol specific function to
  *			store the secret private key along with parameters.
  *			The implementation knows how to decode the buffer
@@ -75,6 +78,8 @@ struct crypto_kpp {
  * @base:		Common crypto API algorithm data structure
  */
 struct kpp_alg {
+	int (*set_secret_raw)(struct crypto_kpp *tfm, const u8 *key,
+			  unsigned int len);
 	int (*set_secret)(struct crypto_kpp *tfm, const void *buffer,
 			  unsigned int len);
 	int (*generate_public_key)(struct kpp_request *req);
@@ -293,6 +298,30 @@ static inline int crypto_kpp_set_secret(struct crypto_kpp *tfm,
 	return crypto_kpp_alg(tfm)->set_secret(tfm, buffer, len);
 }
 
+/**
+ * crypto_kpp_set_secret_raw() - Invoke kpp operation
+ *
+ * Function that works as crypto_kpp_set_secret() but on a non-encoded key
+ * (aka raw binary data).
+ *
+ * @tfm:	tfm handle
+ * @buffer:	Buffer holding the raw representation of the private
+ *		key as raw binary data.
+ * @len:	Length of the private key buffer.
+ *
+ * Return: zero on success; error code in case of error
+ */
+static inline int crypto_kpp_set_secret_raw(struct crypto_kpp *tfm,
+					const u8 *key, unsigned int len)
+{
+	struct kpp_alg *alg = crypto_kpp_alg(tfm);
+
+	if (!alg->set_secret_raw)
+		return -EOPNOTSUPP;
+
+	return alg->set_secret_raw(tfm, key, len);
+}
+
 /**
  * crypto_kpp_generate_public_key() - Invoke kpp operation
  *
-- 
2.34.1

[V1 3/4] crypto ecdh.c: define the ECDH set_secret_raw method

[Rodolfo Giometti]

Adds new function ecdh_set_secret_raw() and sets it as set_secret_raw
method for ecdh_nist_(p192|p256|p384) algorithms.

Signed-off-by: Rodolfo Giometti <giometti@enneenne.com>
---
 crypto/ecdh.c | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/crypto/ecdh.c b/crypto/ecdh.c
index 9f0b93b3166d..548099f26c65 100644
--- a/crypto/ecdh.c
+++ b/crypto/ecdh.c
@@ -52,6 +52,34 @@ static int ecdh_set_secret(struct crypto_kpp *tfm, const void *buf,
 	return ret;
 }
 
+static int ecdh_set_secret_raw(struct crypto_kpp *tfm, const u8 *key,
+			       unsigned int len)
+{
+	struct ecdh params = {
+		.key = key,
+		.key_size = len,
+	};
+	u8 *buf;
+	unsigned int buf_len;
+	int err;
+
+	buf_len = crypto_ecdh_key_len(&params);
+	buf = kmalloc(buf_len, GFP_KERNEL);
+	if (!buf)
+		return -ENOMEM;
+
+	err = crypto_ecdh_encode_key(buf, buf_len, &params);
+	if (err)
+		goto free_buf;
+
+	err = ecdh_set_secret(tfm, buf, buf_len);
+	fallthrough;
+free_buf:
+	kfree_sensitive(buf);
+
+	return err;
+}
+
 static int ecdh_compute_value(struct kpp_request *req)
 {
 	struct crypto_kpp *tfm = crypto_kpp_reqtfm(req);
@@ -139,6 +167,7 @@ static int ecdh_nist_p192_init_tfm(struct crypto_kpp *tfm)
 }
 
 static struct kpp_alg ecdh_nist_p192 = {
+	.set_secret_raw = ecdh_set_secret_raw,
 	.set_secret = ecdh_set_secret,
 	.generate_public_key = ecdh_compute_value,
 	.compute_shared_secret = ecdh_compute_value,
@@ -164,6 +193,7 @@ static int ecdh_nist_p256_init_tfm(struct crypto_kpp *tfm)
 }
 
 static struct kpp_alg ecdh_nist_p256 = {
+	.set_secret_raw = ecdh_set_secret_raw,
 	.set_secret = ecdh_set_secret,
 	.generate_public_key = ecdh_compute_value,
 	.compute_shared_secret = ecdh_compute_value,
@@ -189,6 +219,7 @@ static int ecdh_nist_p384_init_tfm(struct crypto_kpp *tfm)
 }
 
 static struct kpp_alg ecdh_nist_p384 = {
+	.set_secret_raw = ecdh_set_secret_raw,
 	.set_secret = ecdh_set_secret,
 	.generate_public_key = ecdh_compute_value,
 	.compute_shared_secret = ecdh_compute_value,
-- 
2.34.1

Re: [V1 3/4] crypto ecdh.c: define the ECDH set_secret_raw method

[kernel test robot]

Hi Rodolfo,

kernel test robot noticed the following build errors:

[auto build test ERROR on herbert-cryptodev-2.6/master]
[also build test ERROR on herbert-crypto-2.6/master linus/master v6.17-rc6 next-20250912]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Rodolfo-Giometti/crypto-ecdh-h-set-key-memory-region-as-const/20250915-164558
base:   https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
patch link:    https://lore.kernel.org/r/20250915084039.2848952-4-giometti%40enneenne.com
patch subject: [V1 3/4] crypto ecdh.c: define the ECDH set_secret_raw method
config: i386-buildonly-randconfig-002-20250915 (https://download.01.org/0day-ci/archive/20250915/202509152238.lU1NZ63u-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250915/202509152238.lU1NZ63u-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202509152238.lU1NZ63u-lkp@intel.com/

All errors (new ones prefixed by >>):

   In file included from include/linux/compiler_types.h:89,
                    from <command-line>:
   crypto/ecdh.c: In function 'ecdh_set_secret_raw':
>> include/linux/compiler_attributes.h:214:41: error: invalid use of attribute 'fallthrough'
     214 | # define fallthrough                    __attribute__((__fallthrough__))
         |                                         ^~~~~~~~~~~~~
   crypto/ecdh.c:76:9: note: in expansion of macro 'fallthrough'
      76 |         fallthrough;
         |         ^~~~~~~~~~~
--
   In file included from include/linux/compiler_types.h:89,
                    from <command-line>:
   ecdh.c: In function 'ecdh_set_secret_raw':
>> include/linux/compiler_attributes.h:214:41: error: invalid use of attribute 'fallthrough'
     214 | # define fallthrough                    __attribute__((__fallthrough__))
         |                                         ^~~~~~~~~~~~~
   ecdh.c:76:9: note: in expansion of macro 'fallthrough'
      76 |         fallthrough;
         |         ^~~~~~~~~~~


vim +/fallthrough +214 include/linux/compiler_attributes.h

294f69e662d1570 Joe Perches   2019-10-05  201  
294f69e662d1570 Joe Perches   2019-10-05  202  /*
294f69e662d1570 Joe Perches   2019-10-05  203   * Add the pseudo keyword 'fallthrough' so case statement blocks
294f69e662d1570 Joe Perches   2019-10-05  204   * must end with any of these keywords:
294f69e662d1570 Joe Perches   2019-10-05  205   *   break;
294f69e662d1570 Joe Perches   2019-10-05  206   *   fallthrough;
ca0760e7d79e2bb Wei Ming Chen 2021-05-06  207   *   continue;
294f69e662d1570 Joe Perches   2019-10-05  208   *   goto <label>;
294f69e662d1570 Joe Perches   2019-10-05  209   *   return [expression];
294f69e662d1570 Joe Perches   2019-10-05  210   *
294f69e662d1570 Joe Perches   2019-10-05  211   *  gcc: https://gcc.gnu.org/onlinedocs/gcc/Statement-Attributes.html#Statement-Attributes
294f69e662d1570 Joe Perches   2019-10-05  212   */
294f69e662d1570 Joe Perches   2019-10-05  213  #if __has_attribute(__fallthrough__)
294f69e662d1570 Joe Perches   2019-10-05 @214  # define fallthrough                    __attribute__((__fallthrough__))
294f69e662d1570 Joe Perches   2019-10-05  215  #else
294f69e662d1570 Joe Perches   2019-10-05  216  # define fallthrough                    do {} while (0)  /* fallthrough */
a3f8a30f3f0079c Miguel Ojeda  2018-08-30  217  #endif
a3f8a30f3f0079c Miguel Ojeda  2018-08-30  218  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

[V1 4/4] crypto: add user-space interface for KPP algorithms

[Rodolfo Giometti]

It adds a dedicated user interface for the Key-agreement Protocol
Primitive (KPP).

Now, from user applications, we can 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 (better by)
ALG_SET_KEY_BY_KEY_SERIAL, the user program should write the peer's
public key to the socket and then receive its public key followed by
the shared secret calculated by the selected kernel algorithm.

Signed-off-by: Rodolfo Giometti <giometti@enneenne.com>
---
 crypto/Kconfig     |   8 ++
 crypto/Makefile    |   1 +
 crypto/algif_kpp.c | 286 +++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 295 insertions(+)
 create mode 100644 crypto/algif_kpp.c

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 23bd98981ae8..367951444d20 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -1412,6 +1412,14 @@ config CRYPTO_USER_API_AEAD
 	  See Documentation/crypto/userspace-if.rst and
 	  https://www.chronox.de/libkcapi/html/index.html
 
+config CRYPTO_USER_API_KPP
+	tristate "Key-agreement Protocol Primitive"
+	depends on NET
+	select CRYPTO_KPP
+	select CRYPTO_USER_API
+	help
+	  Enable the userspace interface for Key-agreement Protocol Primitive.
+
 config CRYPTO_USER_API_ENABLE_OBSOLETE
 	bool "Obsolete cryptographic algorithms"
 	depends on CRYPTO_USER_API
diff --git a/crypto/Makefile b/crypto/Makefile
index 6c5d59369dac..044d1f194342 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -179,6 +179,7 @@ obj-$(CONFIG_CRYPTO_USER_API_HASH) += algif_hash.o
 obj-$(CONFIG_CRYPTO_USER_API_SKCIPHER) += algif_skcipher.o
 obj-$(CONFIG_CRYPTO_USER_API_RNG) += algif_rng.o
 obj-$(CONFIG_CRYPTO_USER_API_AEAD) += algif_aead.o
+obj-$(CONFIG_CRYPTO_USER_API_KPP) += algif_kpp.o
 obj-$(CONFIG_CRYPTO_ZSTD) += zstd.o
 obj-$(CONFIG_CRYPTO_ECC) += ecc.o
 obj-$(CONFIG_CRYPTO_ESSIV) += essiv.o
diff --git a/crypto/algif_kpp.c b/crypto/algif_kpp.c
new file mode 100644
index 000000000000..9cbb5589889c
--- /dev/null
+++ b/crypto/algif_kpp.c
@@ -0,0 +1,286 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * algif_kpp: User-space interface for KPP algorithms
+ *
+ * This file provides the user-space API for Key-agreement Protocol Primitive
+ * (KPP).
+ *
+ * Copyright (C) 2025 Rodolfo Giometti <giometti@enneenne.com>
+ */
+
+#include <crypto/dh.h>
+#include <crypto/internal/kpp.h>
+#include <crypto/scatterwalk.h>
+#include <crypto/if_alg.h>
+#include <linux/init.h>
+#include <linux/list.h>
+#include <linux/kernel.h>
+#include <linux/mm.h>
+#include <linux/module.h>
+#include <linux/net.h>
+#include <net/sock.h>
+#include <crypto/ecdh.h>
+
+struct alg_kpp_ctx {
+	struct crypto_kpp *tfm;
+	void *peer_pubkey;
+	size_t peer_pubkey_len;
+};
+
+static int kpp_sendmsg(struct socket *sock, struct msghdr *msg, size_t ignored)
+{
+	struct sock *sk = sock->sk;
+	struct alg_sock *ask = alg_sk(sk);
+	struct alg_kpp_ctx *ctx = ask->private;
+	size_t pubkey_len, size;
+	int ret;
+
+	/* Check the user data for proper length */
+	pubkey_len = crypto_kpp_maxsize(ctx->tfm);
+	size = iov_iter_count(&msg->msg_iter);
+	if (pubkey_len == 0 || pubkey_len != size)
+		return -EINVAL;
+
+	/* Read the peer public key */
+	if (ctx->peer_pubkey_len > 0)
+		kfree(ctx->peer_pubkey);
+	ctx->peer_pubkey = kmalloc(pubkey_len, GFP_KERNEL);
+	if (!ctx->peer_pubkey)
+		return -ENOMEM;
+	ctx->peer_pubkey_len = pubkey_len;
+	ret = copy_from_iter(ctx->peer_pubkey, pubkey_len, &msg->msg_iter);
+	if (ret < 0) {
+		kfree(ctx->peer_pubkey);
+		ctx->peer_pubkey_len = 0;
+	}
+
+	return ret;
+}
+
+static int kpp_recvmsg(struct socket *sock, struct msghdr *msg,
+		       size_t ignored, int flags)
+{
+	struct sock *sk = sock->sk;
+	struct alg_sock *ask = alg_sk(sk);
+	struct alg_kpp_ctx *ctx = ask->private;
+	struct kpp_request *req;
+	size_t pubkey_len, size;
+	struct scatterlist sg_in, sg_out;
+	uint8_t *buf;
+	int ret;
+
+	pubkey_len = crypto_kpp_maxsize(ctx->tfm);
+	if (pubkey_len == 0)
+		return -EINVAL;
+
+	/* Check for the user buffer proper length */
+	size = iov_iter_count(&msg->msg_iter);
+	if (size < pubkey_len)
+		return -EINVAL;
+
+	buf = kmalloc(pubkey_len, GFP_KERNEL);
+	if (!buf)
+		return -ENOMEM;
+
+	/* Allocate request buffer */
+	req = kpp_request_alloc(ctx->tfm, GFP_KERNEL);
+	if (IS_ERR(req)) {
+		ret = PTR_ERR(req);
+		goto free_buf;
+	}
+
+	/* Generate our public key */
+	sg_init_one(&sg_out, buf, pubkey_len);
+	kpp_request_set_input(req, NULL, 0);
+	kpp_request_set_output(req, &sg_out, pubkey_len);
+	ret = crypto_kpp_generate_public_key(req);
+	if (ret)
+		goto free_req;
+
+	/* Compute the shared secret */
+	sg_init_one(&sg_in, ctx->peer_pubkey, ctx->peer_pubkey_len);
+	sg_init_one(&sg_out, buf, pubkey_len);
+	kpp_request_set_input(req, &sg_in, ctx->peer_pubkey_len);
+	kpp_request_set_output(req, &sg_out, pubkey_len);
+	ret = crypto_kpp_compute_shared_secret(req);
+	if (ret)
+		goto free_req;
+
+	/* Drop the current peer's key */
+	kfree(ctx->peer_pubkey);
+	ctx->peer_pubkey_len = 0;
+
+	/* Return the shared secret to user space */
+	ret = copy_to_iter(buf, pubkey_len, &msg->msg_iter);
+
+free_req:
+	kpp_request_free(req);
+free_buf:
+	kfree(buf);
+
+	return ret;
+}
+
+static struct proto_ops algif_kpp_ops = {
+	.family = PF_ALG,
+	.release = af_alg_release,
+	.sendmsg = kpp_sendmsg,
+	.recvmsg = kpp_recvmsg,
+};
+
+static int kpp_check_key(struct socket *sock)
+{
+	int err = 0;
+	struct sock *psk;
+	struct alg_sock *pask;
+	struct crypto_kpp *tfm;
+	struct sock *sk = sock->sk;
+	struct alg_sock *ask = alg_sk(sk);
+
+	lock_sock(sk);
+	if (!atomic_read(&ask->nokey_refcnt))
+		goto unlock_child;
+
+	psk = ask->parent;
+	pask = alg_sk(psk);
+	tfm = pask->private;
+
+	err = -ENOKEY;
+	lock_sock_nested(psk, SINGLE_DEPTH_NESTING);
+	if (crypto_kpp_get_flags(tfm) & CRYPTO_TFM_NEED_KEY)
+		goto unlock;
+
+	atomic_dec(&pask->nokey_refcnt);
+	atomic_set(&ask->nokey_refcnt, 0);
+
+	err = 0;
+
+unlock:
+	release_sock(psk);
+unlock_child:
+	release_sock(sk);
+
+	return err;
+}
+
+static int kpp_sendmsg_nokey(struct socket *sock, struct msghdr *msg,
+			     size_t size)
+{
+	int err;
+
+	err = kpp_check_key(sock);
+	if (err)
+		return err;
+
+	return kpp_sendmsg(sock, msg, size);
+}
+
+static int kpp_recvmsg_nokey(struct socket *sock, struct msghdr *msg,
+			     size_t ignored, int flags)
+{
+	int err;
+
+	err = kpp_check_key(sock);
+	if (err)
+		return err;
+
+	return kpp_recvmsg(sock, msg, ignored, flags);
+}
+
+static struct proto_ops algif_kpp_ops_nokey = {
+	.family = PF_ALG,
+	.release = af_alg_release,
+	.sendmsg = kpp_sendmsg_nokey,
+	.recvmsg = kpp_recvmsg_nokey,
+};
+
+static void *kpp_bind(const char *name, u32 type, u32 mask)
+{
+	return crypto_alloc_kpp(name, type, mask);
+}
+
+static void kpp_release(void *private)
+{
+	crypto_free_kpp(private);
+}
+
+static int kpp_set_secret(void *private, const u8 *key, unsigned int keylen)
+{
+	return crypto_kpp_set_secret_raw(private, key, keylen);
+}
+
+static void kpp_sock_destruct_child(struct sock *sk)
+{
+	struct alg_sock *ask = alg_sk(sk);
+	struct alg_kpp_ctx *ctx = ask->private;
+
+	if (ctx) {
+		if (ctx->peer_pubkey_len > 0)
+			kfree(ctx->peer_pubkey);
+		sock_kfree_s(sk, ctx, sizeof(*ctx));
+	}
+
+	af_alg_release_parent(sk);
+}
+
+static int kpp_accept_parent_nokey(void *private, struct sock *sk)
+{
+	struct alg_kpp_ctx *ctx;
+	struct alg_sock *ask = alg_sk(sk);
+	struct crypto_kpp *tfm = private;
+
+	ctx = sock_kmalloc(sk, sizeof(*ctx), GFP_KERNEL);
+	if (!ctx)
+		return -ENOMEM;
+
+	ctx->tfm = tfm;
+	ctx->peer_pubkey = NULL;
+	ctx->peer_pubkey_len = 0;
+	ask->private = ctx;
+
+	sk->sk_destruct = kpp_sock_destruct_child;
+
+	return 0;
+}
+
+static int kpp_accept_parent(void *private, struct sock *sk)
+{
+	struct crypto_kpp *tfm = private;
+
+	if (crypto_kpp_get_flags(tfm) & CRYPTO_TFM_NEED_KEY)
+		return -ENOKEY;
+
+	return kpp_accept_parent_nokey(private, sk);
+}
+
+static const struct af_alg_type algif_type_kpp = {
+	.bind = kpp_bind,
+	.release = kpp_release,
+	.setkey = kpp_set_secret,
+	.accept = kpp_accept_parent,
+	.accept_nokey = kpp_accept_parent_nokey,
+
+	.ops = &algif_kpp_ops,
+	.ops_nokey = &algif_kpp_ops_nokey,
+
+	.name = "kpp",
+	.owner = THIS_MODULE
+};
+
+static int __init algif_kpp_init(void)
+{
+	return af_alg_register_type(&algif_type_kpp);
+}
+
+static void __exit algif_kpp_exit(void)
+{
+	int err = af_alg_unregister_type(&algif_type_kpp);
+
+	WARN_ON_ONCE(err);
+}
+
+module_init(algif_kpp_init);
+module_exit(algif_kpp_exit);
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Rodolfo Giometti <giometti@enneenne.com>");
+MODULE_DESCRIPTION("KPP kernel crypto API user space interface");
-- 
2.34.1

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

[Eric Biggers]

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

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

[Rodolfo Giometti]

On 15/09/25 16:50, Eric Biggers wrote:
> 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.

The main purpose of using this implementation is to be able to use the kernel's 
trusted keys as private keys. Trusted keys are protected by a TPM or other 
hardware device, and being able to generate private keys that can only be 
(de)encapsulated within them is (IMHO) a very useful and secure mechanism for 
storing a private key.

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

I see, but in userspace there is no better way to protect a private key than 
using trusted keys.

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

I think this is true when talking about kernel software implementations, but is 
it the same when we consider possible hardware 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.

I understand your point, so please let me know if I have any chance of this 
patch set (once fixed and revised) being merged into the kernel; otherwise, I'll 
give up right away. :)

Thanks for your considerations.

Ciao,

Rodolfo

-- 
GNU/Linux Solutions                  e-mail: giometti@enneenne.com
Linux Device Driver                          giometti@linux.it
Embedded Systems                     phone:  +39 349 2432127
UNIX programming

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

[Herbert Xu]

On Mon, Sep 15, 2025 at 05:47:56PM +0200, Rodolfo Giometti wrote:
>
> The main purpose of using this implementation is to be able to use the
> kernel's trusted keys as private keys. Trusted keys are protected by a TPM
> or other hardware device, and being able to generate private keys that can
> only be (de)encapsulated within them is (IMHO) a very useful and secure
> mechanism for storing a private key.

If the issue is key management then you should be working with
David Howell on creating an interface that sits on top of the
keyring subsystem.

The Crypto API doesn't care about keys.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

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

[Rodolfo Giometti]

On 16/09/25 06:10, Herbert Xu wrote:
> On Mon, Sep 15, 2025 at 05:47:56PM +0200, Rodolfo Giometti wrote:
>>
>> The main purpose of using this implementation is to be able to use the
>> kernel's trusted keys as private keys. Trusted keys are protected by a TPM
>> or other hardware device, and being able to generate private keys that can
>> only be (de)encapsulated within them is (IMHO) a very useful and secure
>> mechanism for storing a private key.
> 
> If the issue is key management then you should be working with
> David Howell on creating an interface that sits on top of the
> keyring subsystem.
> 
> The Crypto API doesn't care about keys.

No, the problem concerns the use of the Linux keyring (specifically, trusted 
keys and other hardware-managed keys) with cryptographic algorithms.

 From a security standpoint, AF_ALG and keyctl's trusted keys are a perfect 
match to manage secure encryption and decryption, so why not do the same with 
KPP operations (or other cryptographic operations)?

I know there might be issues with allowing user space to use this interface, but:

1) I think this mechanism can get its best when implemented in hardware, and

2) (hey!) we're developers who know what they're doing! :)

This patch series is just a sample of the improvements I'd like to make on this 
front. Please tell me if you don't intend to add these mechanisms to the kernel 
at all, or if I have any chances, so I can decide whether to proceed or stop here.

Ciao,

Rodolfo

-- 
GNU/Linux Solutions                  e-mail: giometti@enneenne.com
Linux Device Driver                          giometti@linux.it
Embedded Systems                     phone:  +39 349 2432127
UNIX programming

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

[Ignat Korchagin]

On Tue, Sep 16, 2025 at 9:22 AM Rodolfo Giometti <giometti@enneenne.com> wrote:
>
> On 16/09/25 06:10, Herbert Xu wrote:
> > On Mon, Sep 15, 2025 at 05:47:56PM +0200, Rodolfo Giometti wrote:
> >>
> >> The main purpose of using this implementation is to be able to use the
> >> kernel's trusted keys as private keys. Trusted keys are protected by a TPM
> >> or other hardware device, and being able to generate private keys that can
> >> only be (de)encapsulated within them is (IMHO) a very useful and secure
> >> mechanism for storing a private key.
> >
> > If the issue is key management then you should be working with
> > David Howell on creating an interface that sits on top of the
> > keyring subsystem.
> >
> > The Crypto API doesn't care about keys.
>
> No, the problem concerns the use of the Linux keyring (specifically, trusted
> keys and other hardware-managed keys) with cryptographic algorithms.
>
>  From a security standpoint, AF_ALG and keyctl's trusted keys are a perfect
> match to manage secure encryption and decryption, so why not do the same with
> KPP operations (or other cryptographic operations)?

I generally find the AF_ALG API ugly to use, but I can see the use
case for symmetric algorithms, where one needs to encrypt/decrypt a
large stream in chunks. For asymmetric operations, like signing and
KPP it doesn't make much sense to go through the socket API. In fact
we already have an established interface through keyctl(2).

Now, in my opinion, the fundamental problem here is that we want to
use trusted keys as asymmetric keys, where currently they are just
binary blobs from a kernel perspective (so suitable only for symmetric
use). So instead of the AF_ALG extension we need a way to "cast" a
trusted key to an asymmetric key and once it is "cast" (or type
changed somehow) - we can use the established keyring interfaces both
for signatures and KPP. For example, what if we somehow extend the
add_key(2)/request_key(2) syscalls to be able to initialise an
asymmetric key from a trusted key payload instead of providing the
payload directly via a buffer (similar to how
ALG_SET_KEY_BY_KEY_SERIAL does it for symmetric keys for socket crypto
API)?

Ignat

> I know there might be issues with allowing user space to use this interface, but:
>
> 1) I think this mechanism can get its best when implemented in hardware, and
>
> 2) (hey!) we're developers who know what they're doing! :)
>
> This patch series is just a sample of the improvements I'd like to make on this
> front. Please tell me if you don't intend to add these mechanisms to the kernel
> at all, or if I have any chances, so I can decide whether to proceed or stop here.
>
> Ciao,
>
> Rodolfo
>
> --
> GNU/Linux Solutions                  e-mail: giometti@enneenne.com
> Linux Device Driver                          giometti@linux.it
> Embedded Systems                     phone:  +39 349 2432127
> UNIX programming

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

[Rodolfo Giometti]

On 16/09/25 12:21, Ignat Korchagin wrote:
> On Tue, Sep 16, 2025 at 9:22 AM Rodolfo Giometti <giometti@enneenne.com> wrote:
>>
>> On 16/09/25 06:10, Herbert Xu wrote:
>>> On Mon, Sep 15, 2025 at 05:47:56PM +0200, Rodolfo Giometti wrote:
>>>>
>>>> The main purpose of using this implementation is to be able to use the
>>>> kernel's trusted keys as private keys. Trusted keys are protected by a TPM
>>>> or other hardware device, and being able to generate private keys that can
>>>> only be (de)encapsulated within them is (IMHO) a very useful and secure
>>>> mechanism for storing a private key.
>>>
>>> If the issue is key management then you should be working with
>>> David Howell on creating an interface that sits on top of the
>>> keyring subsystem.
>>>
>>> The Crypto API doesn't care about keys.
>>
>> No, the problem concerns the use of the Linux keyring (specifically, trusted
>> keys and other hardware-managed keys) with cryptographic algorithms.
>>
>>   From a security standpoint, AF_ALG and keyctl's trusted keys are a perfect
>> match to manage secure encryption and decryption, so why not do the same with
>> KPP operations (or other cryptographic operations)?
> 
> I generally find the AF_ALG API ugly to use, but I can see the use
> case for symmetric algorithms, where one needs to encrypt/decrypt a
> large stream in chunks. For asymmetric operations, like signing and
> KPP it doesn't make much sense to go through the socket API. In fact
> we already have an established interface through keyctl(2).

I see, but if we consider shared secret support, for example, keyctl doesn't 
support ECDH, while AF_ALG allows you to choose whether to use DH or ECDH. 
Furthermore, AF_ALG allows us to choose which driver actually performs the 
encryption operation!

In my opinion, keyctl is excellent for managing key generation and access, but 
using AF_ALG for using them isn't entirely wrong even in the case of asymmetric 
keys and, in my opinion, is much more versatile.

> Now, in my opinion, the fundamental problem here is that we want to
> use trusted keys as asymmetric keys, where currently they are just
> binary blobs from a kernel perspective (so suitable only for symmetric
> use). So instead of the AF_ALG extension we need a way to "cast" a
> trusted key to an asymmetric key and once it is "cast" (or type
> changed somehow) - we can use the established keyring interfaces both
> for signatures and KPP.

IMHO the fact that trusted keys are binary blobs is perfect for use with AF_ALG, 
where we can specify different algorithms to operate on. :)

Ciao,

Rodolfo

-- 
GNU/Linux Solutions                  e-mail: giometti@enneenne.com
Linux Device Driver                          giometti@linux.it
Embedded Systems                     phone:  +39 349 2432127
UNIX programming

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

[Ignat Korchagin]

On Tue, Sep 16, 2025 at 12:21 PM Rodolfo Giometti <giometti@enneenne.com> wrote:
>
> On 16/09/25 12:21, Ignat Korchagin wrote:
> > On Tue, Sep 16, 2025 at 9:22 AM Rodolfo Giometti <giometti@enneenne.com> wrote:
> >>
> >> On 16/09/25 06:10, Herbert Xu wrote:
> >>> On Mon, Sep 15, 2025 at 05:47:56PM +0200, Rodolfo Giometti wrote:
> >>>>
> >>>> The main purpose of using this implementation is to be able to use the
> >>>> kernel's trusted keys as private keys. Trusted keys are protected by a TPM
> >>>> or other hardware device, and being able to generate private keys that can
> >>>> only be (de)encapsulated within them is (IMHO) a very useful and secure
> >>>> mechanism for storing a private key.
> >>>
> >>> If the issue is key management then you should be working with
> >>> David Howell on creating an interface that sits on top of the
> >>> keyring subsystem.
> >>>
> >>> The Crypto API doesn't care about keys.
> >>
> >> No, the problem concerns the use of the Linux keyring (specifically, trusted
> >> keys and other hardware-managed keys) with cryptographic algorithms.
> >>
> >>   From a security standpoint, AF_ALG and keyctl's trusted keys are a perfect
> >> match to manage secure encryption and decryption, so why not do the same with
> >> KPP operations (or other cryptographic operations)?
> >
> > I generally find the AF_ALG API ugly to use, but I can see the use
> > case for symmetric algorithms, where one needs to encrypt/decrypt a
> > large stream in chunks. For asymmetric operations, like signing and
> > KPP it doesn't make much sense to go through the socket API. In fact
> > we already have an established interface through keyctl(2).
>
> I see, but if we consider shared secret support, for example, keyctl doesn't
> support ECDH, while AF_ALG allows you to choose whether to use DH or ECDH.

But this is exactly the point: unlike symmetric algorithms, where you
can just use any blob with any algorithm, you can't use an RSA key for
ECDH for example. That is, you cannot arbitrarily select an algorithm
for any key and the algorithm is a property attached to the key
itself. So if you "cast" a blob to an EC key, you would need to select
the algorithm at cast time and the implementation should validate if
the blob actually represents a valid EC key (with all the proper
checks, like if the key is an a big in and is less than the order
group etc). With AF_ALG you would need to do this validation for every
crypto operation, which is not very efficient at the very least.

> Furthermore, AF_ALG allows us to choose which driver actually performs the
> encryption operation!

This is indeed a limitation of the current keyctl interface, but again
- we probably should not select the algorithm here, but we should
consider extending it so the user can specify a particular crypto
driver/implementation.

> In my opinion, keyctl is excellent for managing key generation and access, but
> using AF_ALG for using them isn't entirely wrong even in the case of asymmetric
> keys and, in my opinion, is much more versatile.
>
> > Now, in my opinion, the fundamental problem here is that we want to
> > use trusted keys as asymmetric keys, where currently they are just
> > binary blobs from a kernel perspective (so suitable only for symmetric
> > use). So instead of the AF_ALG extension we need a way to "cast" a
> > trusted key to an asymmetric key and once it is "cast" (or type
> > changed somehow) - we can use the established keyring interfaces both
> > for signatures and KPP.
>
> IMHO the fact that trusted keys are binary blobs is perfect for use with AF_ALG,
> where we can specify different algorithms to operate on. :)
>
> Ciao,
>
> Rodolfo
>
> --
> GNU/Linux Solutions                  e-mail: giometti@enneenne.com
> Linux Device Driver                          giometti@linux.it
> Embedded Systems                     phone:  +39 349 2432127
> UNIX programming

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

[Rodolfo Giometti]

On 16/09/25 13:56, Ignat Korchagin wrote:
> On Tue, Sep 16, 2025 at 12:21 PM Rodolfo Giometti <giometti@enneenne.com> wrote:
>>
>> On 16/09/25 12:21, Ignat Korchagin wrote:
>>> On Tue, Sep 16, 2025 at 9:22 AM Rodolfo Giometti <giometti@enneenne.com> wrote:
>>>>
>>>> On 16/09/25 06:10, Herbert Xu wrote:
>>>>> On Mon, Sep 15, 2025 at 05:47:56PM +0200, Rodolfo Giometti wrote:
>>>>>>
>>>>>> The main purpose of using this implementation is to be able to use the
>>>>>> kernel's trusted keys as private keys. Trusted keys are protected by a TPM
>>>>>> or other hardware device, and being able to generate private keys that can
>>>>>> only be (de)encapsulated within them is (IMHO) a very useful and secure
>>>>>> mechanism for storing a private key.
>>>>>
>>>>> If the issue is key management then you should be working with
>>>>> David Howell on creating an interface that sits on top of the
>>>>> keyring subsystem.
>>>>>
>>>>> The Crypto API doesn't care about keys.
>>>>
>>>> No, the problem concerns the use of the Linux keyring (specifically, trusted
>>>> keys and other hardware-managed keys) with cryptographic algorithms.
>>>>
>>>>    From a security standpoint, AF_ALG and keyctl's trusted keys are a perfect
>>>> match to manage secure encryption and decryption, so why not do the same with
>>>> KPP operations (or other cryptographic operations)?
>>>
>>> I generally find the AF_ALG API ugly to use, but I can see the use
>>> case for symmetric algorithms, where one needs to encrypt/decrypt a
>>> large stream in chunks. For asymmetric operations, like signing and
>>> KPP it doesn't make much sense to go through the socket API. In fact
>>> we already have an established interface through keyctl(2).
>>
>> I see, but if we consider shared secret support, for example, keyctl doesn't
>> support ECDH, while AF_ALG allows you to choose whether to use DH or ECDH.
> 
> But this is exactly the point: unlike symmetric algorithms, where you
> can just use any blob with any algorithm, you can't use an RSA key for
> ECDH for example. That is, you cannot arbitrarily select an algorithm
> for any key and the algorithm is a property attached to the key
> itself. So if you "cast" a blob to an EC key, you would need to select
> the algorithm at cast time and the implementation should validate if
> the blob actually represents a valid EC key (with all the proper
> checks, like if the key is an a big in and is less than the order
> group etc).

I understand your point; however, I believe that allowing the AF_ALG developer 
to use a generic data blob (of the appropriate size, of course) as a key is more 
versatile and allows for easier implementation of future extensions.

> With AF_ALG you would need to do this validation for every
> crypto operation, which is not very efficient at the very least.

I think this might be acceptable if we consider the security we gain compared to 
using any existing user-space implementation!

>> Furthermore, AF_ALG allows us to choose which driver actually performs the
>> encryption operation!
> 
> This is indeed a limitation of the current keyctl interface, but again
> - we probably should not select the algorithm here, but we should
> consider extending it so the user can specify a particular crypto
> driver/implementation.

Furthermore, I think one solution isn't mutually exclusive. So, why not give the 
developer the freedom to choose which interface to use? ;)

Furthermore, there's nothing stopping us from strengthening the current AF_ALG 
support so that it can also be used well with asymmetric keys.

>> In my opinion, keyctl is excellent for managing key generation and access, but
>> using AF_ALG for using them isn't entirely wrong even in the case of asymmetric
>> keys and, in my opinion, is much more versatile.
>>
>>> Now, in my opinion, the fundamental problem here is that we want to
>>> use trusted keys as asymmetric keys, where currently they are just
>>> binary blobs from a kernel perspective (so suitable only for symmetric
>>> use). So instead of the AF_ALG extension we need a way to "cast" a
>>> trusted key to an asymmetric key and once it is "cast" (or type
>>> changed somehow) - we can use the established keyring interfaces both
>>> for signatures and KPP.
>>
>> IMHO the fact that trusted keys are binary blobs is perfect for use with AF_ALG,
>> where we can specify different algorithms to operate on. :)
>>
>> Ciao,
>>
>> Rodolfo
>>
>> --
>> GNU/Linux Solutions                  e-mail: giometti@enneenne.com
>> Linux Device Driver                          giometti@linux.it
>> Embedded Systems                     phone:  +39 349 2432127
>> UNIX programming


-- 
GNU/Linux Solutions                  e-mail: giometti@enneenne.com
Linux Device Driver                          giometti@linux.it
Embedded Systems                     phone:  +39 349 2432127
UNIX programming

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

[Ignat Korchagin]

On Tue, Sep 16, 2025 at 1:33 PM Rodolfo Giometti <giometti@enneenne.com> wrote:
>
> On 16/09/25 13:56, Ignat Korchagin wrote:
> > On Tue, Sep 16, 2025 at 12:21 PM Rodolfo Giometti <giometti@enneenne.com> wrote:
> >>
> >> On 16/09/25 12:21, Ignat Korchagin wrote:
> >>> On Tue, Sep 16, 2025 at 9:22 AM Rodolfo Giometti <giometti@enneenne.com> wrote:
> >>>>
> >>>> On 16/09/25 06:10, Herbert Xu wrote:
> >>>>> On Mon, Sep 15, 2025 at 05:47:56PM +0200, Rodolfo Giometti wrote:
> >>>>>>
> >>>>>> The main purpose of using this implementation is to be able to use the
> >>>>>> kernel's trusted keys as private keys. Trusted keys are protected by a TPM
> >>>>>> or other hardware device, and being able to generate private keys that can
> >>>>>> only be (de)encapsulated within them is (IMHO) a very useful and secure
> >>>>>> mechanism for storing a private key.
> >>>>>
> >>>>> If the issue is key management then you should be working with
> >>>>> David Howell on creating an interface that sits on top of the
> >>>>> keyring subsystem.
> >>>>>
> >>>>> The Crypto API doesn't care about keys.
> >>>>
> >>>> No, the problem concerns the use of the Linux keyring (specifically, trusted
> >>>> keys and other hardware-managed keys) with cryptographic algorithms.
> >>>>
> >>>>    From a security standpoint, AF_ALG and keyctl's trusted keys are a perfect
> >>>> match to manage secure encryption and decryption, so why not do the same with
> >>>> KPP operations (or other cryptographic operations)?
> >>>
> >>> I generally find the AF_ALG API ugly to use, but I can see the use
> >>> case for symmetric algorithms, where one needs to encrypt/decrypt a
> >>> large stream in chunks. For asymmetric operations, like signing and
> >>> KPP it doesn't make much sense to go through the socket API. In fact
> >>> we already have an established interface through keyctl(2).
> >>
> >> I see, but if we consider shared secret support, for example, keyctl doesn't
> >> support ECDH, while AF_ALG allows you to choose whether to use DH or ECDH.
> >
> > But this is exactly the point: unlike symmetric algorithms, where you
> > can just use any blob with any algorithm, you can't use an RSA key for
> > ECDH for example. That is, you cannot arbitrarily select an algorithm
> > for any key and the algorithm is a property attached to the key
> > itself. So if you "cast" a blob to an EC key, you would need to select
> > the algorithm at cast time and the implementation should validate if
> > the blob actually represents a valid EC key (with all the proper
> > checks, like if the key is an a big in and is less than the order
> > group etc).
>
> I understand your point; however, I believe that allowing the AF_ALG developer
> to use a generic data blob (of the appropriate size, of course) as a key is more
> versatile and allows for easier implementation of future extensions.
>
> > With AF_ALG you would need to do this validation for every
> > crypto operation, which is not very efficient at the very least.
>
> I think this might be acceptable if we consider the security we gain compared to
> using any existing user-space implementation!

I don't think the alternative approach I proposed compromises on
security. That is it has the same security level (using a trusted key
to do ECDH without exposing it to userspace). Unless I'm missing
something?

> >> Furthermore, AF_ALG allows us to choose which driver actually performs the
> >> encryption operation!
> >
> > This is indeed a limitation of the current keyctl interface, but again
> > - we probably should not select the algorithm here, but we should
> > consider extending it so the user can specify a particular crypto
> > driver/implementation.
>
> Furthermore, I think one solution isn't mutually exclusive. So, why not give the
> developer the freedom to choose which interface to use? ;)
>
> Furthermore, there's nothing stopping us from strengthening the current AF_ALG
> support so that it can also be used well with asymmetric keys.
>
> >> In my opinion, keyctl is excellent for managing key generation and access, but
> >> using AF_ALG for using them isn't entirely wrong even in the case of asymmetric
> >> keys and, in my opinion, is much more versatile.
> >>
> >>> Now, in my opinion, the fundamental problem here is that we want to
> >>> use trusted keys as asymmetric keys, where currently they are just
> >>> binary blobs from a kernel perspective (so suitable only for symmetric
> >>> use). So instead of the AF_ALG extension we need a way to "cast" a
> >>> trusted key to an asymmetric key and once it is "cast" (or type
> >>> changed somehow) - we can use the established keyring interfaces both
> >>> for signatures and KPP.
> >>
> >> IMHO the fact that trusted keys are binary blobs is perfect for use with AF_ALG,
> >> where we can specify different algorithms to operate on. :)
> >>
> >> Ciao,
> >>
> >> Rodolfo
> >>
> >> --
> >> GNU/Linux Solutions                  e-mail: giometti@enneenne.com
> >> Linux Device Driver                          giometti@linux.it
> >> Embedded Systems                     phone:  +39 349 2432127
> >> UNIX programming
>
>
> --
> GNU/Linux Solutions                  e-mail: giometti@enneenne.com
> Linux Device Driver                          giometti@linux.it
> Embedded Systems                     phone:  +39 349 2432127
> UNIX programming

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

[Rodolfo Giometti]

On 16/09/25 14:43, Ignat Korchagin wrote:
> On Tue, Sep 16, 2025 at 1:33 PM Rodolfo Giometti <giometti@enneenne.com> wrote:
>>
>> On 16/09/25 13:56, Ignat Korchagin wrote:
>>> On Tue, Sep 16, 2025 at 12:21 PM Rodolfo Giometti <giometti@enneenne.com> wrote:
>>>>
>>>> On 16/09/25 12:21, Ignat Korchagin wrote:
>>>>> On Tue, Sep 16, 2025 at 9:22 AM Rodolfo Giometti <giometti@enneenne.com> wrote:
>>>>>>
>>>>>> On 16/09/25 06:10, Herbert Xu wrote:
>>>>>>> On Mon, Sep 15, 2025 at 05:47:56PM +0200, Rodolfo Giometti wrote:
>>>>>>>>
>>>>>>>> The main purpose of using this implementation is to be able to use the
>>>>>>>> kernel's trusted keys as private keys. Trusted keys are protected by a TPM
>>>>>>>> or other hardware device, and being able to generate private keys that can
>>>>>>>> only be (de)encapsulated within them is (IMHO) a very useful and secure
>>>>>>>> mechanism for storing a private key.
>>>>>>>
>>>>>>> If the issue is key management then you should be working with
>>>>>>> David Howell on creating an interface that sits on top of the
>>>>>>> keyring subsystem.
>>>>>>>
>>>>>>> The Crypto API doesn't care about keys.
>>>>>>
>>>>>> No, the problem concerns the use of the Linux keyring (specifically, trusted
>>>>>> keys and other hardware-managed keys) with cryptographic algorithms.
>>>>>>
>>>>>>     From a security standpoint, AF_ALG and keyctl's trusted keys are a perfect
>>>>>> match to manage secure encryption and decryption, so why not do the same with
>>>>>> KPP operations (or other cryptographic operations)?
>>>>>
>>>>> I generally find the AF_ALG API ugly to use, but I can see the use
>>>>> case for symmetric algorithms, where one needs to encrypt/decrypt a
>>>>> large stream in chunks. For asymmetric operations, like signing and
>>>>> KPP it doesn't make much sense to go through the socket API. In fact
>>>>> we already have an established interface through keyctl(2).
>>>>
>>>> I see, but if we consider shared secret support, for example, keyctl doesn't
>>>> support ECDH, while AF_ALG allows you to choose whether to use DH or ECDH.
>>>
>>> But this is exactly the point: unlike symmetric algorithms, where you
>>> can just use any blob with any algorithm, you can't use an RSA key for
>>> ECDH for example. That is, you cannot arbitrarily select an algorithm
>>> for any key and the algorithm is a property attached to the key
>>> itself. So if you "cast" a blob to an EC key, you would need to select
>>> the algorithm at cast time and the implementation should validate if
>>> the blob actually represents a valid EC key (with all the proper
>>> checks, like if the key is an a big in and is less than the order
>>> group etc).
>>
>> I understand your point; however, I believe that allowing the AF_ALG developer
>> to use a generic data blob (of the appropriate size, of course) as a key is more
>> versatile and allows for easier implementation of future extensions.
>>
>>> With AF_ALG you would need to do this validation for every
>>> crypto operation, which is not very efficient at the very least.
>>
>> I think this might be acceptable if we consider the security we gain compared to
>> using any existing user-space implementation!
> 
> I don't think the alternative approach I proposed compromises on
> security. That is it has the same security level (using a trusted key
> to do ECDH without exposing it to userspace). Unless I'm missing
> something?

Sorry, my bad. I wasn't referring to your suggestion but to any other user-space 
only KPP (or signature) implementation that doesn't use trusted keys (e.g., 
OpenSSL, etc.).

>>>> Furthermore, AF_ALG allows us to choose which driver actually performs the
>>>> encryption operation!
>>>
>>> This is indeed a limitation of the current keyctl interface, but again
>>> - we probably should not select the algorithm here, but we should
>>> consider extending it so the user can specify a particular crypto
>>> driver/implementation.
>>
>> Furthermore, I think one solution isn't mutually exclusive. So, why not give the
>> developer the freedom to choose which interface to use? ;)
>>
>> Furthermore, there's nothing stopping us from strengthening the current AF_ALG
>> support so that it can also be used well with asymmetric keys.
>>
>>>> In my opinion, keyctl is excellent for managing key generation and access, but
>>>> using AF_ALG for using them isn't entirely wrong even in the case of asymmetric
>>>> keys and, in my opinion, is much more versatile.
>>>>
>>>>> Now, in my opinion, the fundamental problem here is that we want to
>>>>> use trusted keys as asymmetric keys, where currently they are just
>>>>> binary blobs from a kernel perspective (so suitable only for symmetric
>>>>> use). So instead of the AF_ALG extension we need a way to "cast" a
>>>>> trusted key to an asymmetric key and once it is "cast" (or type
>>>>> changed somehow) - we can use the established keyring interfaces both
>>>>> for signatures and KPP.
>>>>
>>>> IMHO the fact that trusted keys are binary blobs is perfect for use with AF_ALG,
>>>> where we can specify different algorithms to operate on. :)
>>>>
>>>> Ciao,
>>>>
>>>> Rodolfo
>>>>
>>>> --
>>>> GNU/Linux Solutions                  e-mail: giometti@enneenne.com
>>>> Linux Device Driver                          giometti@linux.it
>>>> Embedded Systems                     phone:  +39 349 2432127
>>>> UNIX programming
>>
>>
>> --
>> GNU/Linux Solutions                  e-mail: giometti@enneenne.com
>> Linux Device Driver                          giometti@linux.it
>> Embedded Systems                     phone:  +39 349 2432127
>> UNIX programming


-- 
GNU/Linux Solutions                  e-mail: giometti@enneenne.com
Linux Device Driver                          giometti@linux.it
Embedded Systems                     phone:  +39 349 2432127
UNIX programming

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

[Simo Sorce]

On Tue, 2025-09-16 at 14:33 +0200, Rodolfo Giometti wrote:
> I understand your point; however, I believe that allowing the AF_ALG developer 
> to use a generic data blob (of the appropriate size, of course) as a key is more 
> versatile and allows for easier implementation of future extensions.

The only thing something like this allow is huge foot guns.

The current trend in cryptography circles is the exact opposite, ie
strong typing where keys are defined such that they can be used for a
single purpose even when the general mechanisms allows different
operations.

Ie even if an algorithm that allows both encryption and signing the key
is specified to be used only for one or the other operation with
metadata that accompanies they key itself at all times
so the cryptographic implementation can enforce the binding and fail
the un-permitted operation.

In general using random blobs as asymmetric keys is just not possible,
the size alone is no guarantee you have a valid key, so you would have
to spend significant amount of CPU cycles to validate that the blob is
a valid key for the given algorithm, rendering any HW acceleration
effectively pointless by the time you cross all the layers, context
switch back and forth from the kernel, validate the blobs and all.

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