linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/3] Implementation of Ascon-Hash256
@ 2025-12-15  7:54 Rusydi H. Makarim
  2025-12-15  7:54 ` [PATCH 1/3] lib/crypto: Add KUnit test vectors for Ascon-Hash256 Rusydi H. Makarim
                   ` (3 more replies)
  0 siblings, 4 replies; 17+ messages in thread
From: Rusydi H. Makarim @ 2025-12-15  7:54 UTC (permalink / raw)
  To: Herbert Xu, David S. Miller, Eric Biggers, Jason A. Donenfeld,
	Ard Biesheuvel
  Cc: linux-kernel, linux-crypto, Rusydi H. Makarim

This patch implements Ascon-Hash256. Ascon-Hash256 is a hash function as a part
	of the Ascon-Based Lightweight Cryptography Standards for Constrained Devices,
	published as NIST SP 800-232 (https://csrc.nist.gov/pubs/sp/800/232/final).

Signed-off-by: Rusydi H. Makarim <rusydi.makarim@kriptograf.id>
---
Rusydi H. Makarim (3):
      lib/crypto: Add KUnit test vectors for Ascon-Hash256
      lib/crypto: Initial implementation of Ascon-Hash256
      crypto: Crypto API implementation of Ascon-Hash256

 crypto/Kconfig                         |   7 +
 crypto/Makefile                        |   1 +
 crypto/ascon_hash.c                    |  86 ++++++++++++
 include/crypto/ascon_hash.h            |  97 ++++++++++++++
 lib/crypto/Kconfig                     |   8 ++
 lib/crypto/Makefile                    |   5 +
 lib/crypto/ascon_hash.c                | 154 +++++++++++++++++++++
 lib/crypto/hash_info.c                 |   2 +
 lib/crypto/tests/Kconfig               |   9 ++
 lib/crypto/tests/Makefile              |   1 +
 lib/crypto/tests/ascon_hash-testvecs.h | 235 +++++++++++++++++++++++++++++++++
 lib/crypto/tests/ascon_hash_kunit.c    |  33 +++++
 12 files changed, 638 insertions(+)
---
base-commit: 92de2d349e02c2dd96d8d1b7016cc78cf80fc085
change-id: 20251214-ascon_hash256-704130f41b29

Best regards,
-- 
Rusydi H. Makarim <rusydi.makarim@kriptograf.id>


^ permalink raw reply	[flat|nested] 17+ messages in thread

* [PATCH 1/3] lib/crypto: Add KUnit test vectors for Ascon-Hash256
  2025-12-15  7:54 [PATCH 0/3] Implementation of Ascon-Hash256 Rusydi H. Makarim
@ 2025-12-15  7:54 ` Rusydi H. Makarim
  2025-12-19  4:29   ` kernel test robot
  2025-12-22 17:11   ` kernel test robot
  2025-12-15  7:54 ` [PATCH 2/3] lib/crypto: Initial implementation of Ascon-Hash256 Rusydi H. Makarim
                   ` (2 subsequent siblings)
  3 siblings, 2 replies; 17+ messages in thread
From: Rusydi H. Makarim @ 2025-12-15  7:54 UTC (permalink / raw)
  To: Herbert Xu, David S. Miller, Eric Biggers, Jason A. Donenfeld,
	Ard Biesheuvel
  Cc: linux-kernel, linux-crypto, Rusydi H. Makarim

	    Add test vectors to test the implementation correctness.
	    The test vectors are generated using the Python reference
            implementation in https://github.com/meichlseder/pyascon.
            The messages are generated using the method rand_bytes()
            in scripts/crypto/gen-hash-testvecs.py.

Signed-off-by: Rusydi H. Makarim <rusydi.makarim@kriptograf.id>
---
 include/crypto/ascon_hash.h            |  97 ++++++++++++++
 lib/crypto/tests/Kconfig               |   9 ++
 lib/crypto/tests/Makefile              |   1 +
 lib/crypto/tests/ascon_hash-testvecs.h | 235 +++++++++++++++++++++++++++++++++
 lib/crypto/tests/ascon_hash_kunit.c    |  33 +++++
 5 files changed, 375 insertions(+)

diff --git a/include/crypto/ascon_hash.h b/include/crypto/ascon_hash.h
new file mode 100644
index 000000000000..bb3561a745a9
--- /dev/null
+++ b/include/crypto/ascon_hash.h
@@ -0,0 +1,97 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Common values for Ascon-Hash family of algorithms as defined in
+ * NIST SP 800-232 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-232.pdf
+ */
+#ifndef _CRYPTO_ASCON_HASH_H_
+#define _CRYPTO_ASCON_HASH_H_
+
+#include <linux/types.h>
+
+#define ASCON_STATE_SIZE	40
+#define ASCON_STATE_WORDS	5
+
+#define ASCON_HASH256_DIGEST_SIZE	32
+#define ASCON_HASH256_BLOCK_SIZE	8
+#define ASCON_HASH256_RATE		8
+#define ASCON_HASH256_IV		0x0000080100CC0002ULL
+
+/*
+ * The standard of Ascon permutation in NIST SP 800-232 specifies 16 round
+ * constants to accomodate potential functionality extensions in the future
+ * (see page 2).
+ */
+static const u64 ascon_p_rndc[] = {
+	0x000000000000003cULL, 0x000000000000002dULL, 0x000000000000001eULL,
+	0x000000000000000fULL, 0x00000000000000f0ULL, 0x00000000000000e1ULL,
+	0x00000000000000d2ULL, 0x00000000000000c3ULL, 0x00000000000000b4ULL,
+	0x00000000000000a5ULL, 0x0000000000000096ULL, 0x0000000000000087ULL,
+	0x0000000000000078ULL, 0x0000000000000069ULL, 0x000000000000005aULL,
+	0x000000000000004bULL,
+};
+
+/*
+ * State for Ascon-p[320] permutation: 5 64-bit words
+ */
+struct ascon_state {
+	union {
+		__le64 words[ASCON_STATE_WORDS];
+		u8 bytes[ASCON_STATE_SIZE];
+		u64 native_words[ASCON_STATE_WORDS];
+	};
+};
+
+/* Internal context */
+struct __ascon_hash_ctx {
+	struct ascon_state state;
+	u8 absorb_offset;
+};
+
+/**
+ * struct ascon_hash256_ctx - Context for Ascon-Hash256
+ * @ctx: private
+ */
+struct ascon_hash256_ctx {
+	struct __ascon_hash_ctx ctx;
+};
+
+
+/**
+ * ascon_hash256_init() - Initialize a context for Ascon-Hash256
+ * @ctx: The context to initialize
+ *
+ * This begins a new Ascon-Hash256 message digest computation.
+ */
+void ascon_hash256_init(struct ascon_hash256_ctx *ctx);
+
+/**
+ * ascon_hash256_update() - Update an Ascon-Hash256 digest context with input data
+ * @ctx: The context to update; must have been initialized
+ * @in: The input data
+ * @in_len: Length of the input data in bytes
+ */
+void ascon_hash256_update(struct ascon_hash256_ctx *ctx, const u8 *in,
+			  size_t in_len);
+
+/**
+ * ascon_hash256_final() - Finish computing an Ascon-Hash256 message digest
+ * @ctx: The context to finalize; must have been initialized
+ * @out: (output) The resulting Ascon-Hash256 message digest, matching the init
+ *       function that was called.
+ */
+void ascon_hash256_final(struct ascon_hash256_ctx *ctx,
+			 u8 out[ASCON_HASH256_DIGEST_SIZE]);
+
+/**
+ * ascon_hash256() - Compute Ascon-Hash256 digest in one shot
+ * @in: The input data to be digested
+ * @in_len: Length of the input data in bytes
+ * @out: The buffer into which the digest will be stored
+ *
+ * Convenience function that computes an Ascon-Hash256 digest. Use this instead of
+ * the incremental API if you are able to provide all the input at once.
+ */
+void ascon_hash256(const u8 *in, size_t in_len,
+		   u8 out[ASCON_HASH256_DIGEST_SIZE]);
+
+#endif
diff --git a/lib/crypto/tests/Kconfig b/lib/crypto/tests/Kconfig
index 61d435c450bb..e9d10c580ffe 100644
--- a/lib/crypto/tests/Kconfig
+++ b/lib/crypto/tests/Kconfig
@@ -101,6 +101,15 @@ config CRYPTO_LIB_SHA3_KUNIT_TEST
 	  including SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128 and
 	  SHAKE256.
 
+config CRYPTO_LIB_ASCON_HASH_KUNIT_TEST
+	tristate "KUnit tests for Ascon-Hash" if !KUNIT_ALL_TESTS
+	depends on KUNIT
+	default KUNIT_ALL_TESTS || CRYPTO_SELFTESTS
+	select CRYPTO_LIB_BENCHMARK_VISIBLE
+	select CRYPTO_LIB_ASCON_HASH
+	help
+	  KUnit tests for the Ascon-Hash256 cryptographic has functions.
+
 config CRYPTO_LIB_BENCHMARK_VISIBLE
 	bool
 
diff --git a/lib/crypto/tests/Makefile b/lib/crypto/tests/Makefile
index 5109a0651925..59c4f4ef5b22 100644
--- a/lib/crypto/tests/Makefile
+++ b/lib/crypto/tests/Makefile
@@ -10,3 +10,4 @@ obj-$(CONFIG_CRYPTO_LIB_SHA1_KUNIT_TEST) += sha1_kunit.o
 obj-$(CONFIG_CRYPTO_LIB_SHA256_KUNIT_TEST) += sha224_kunit.o sha256_kunit.o
 obj-$(CONFIG_CRYPTO_LIB_SHA512_KUNIT_TEST) += sha384_kunit.o sha512_kunit.o
 obj-$(CONFIG_CRYPTO_LIB_SHA3_KUNIT_TEST) += sha3_kunit.o
+obj-$(CONFIG_CRYPTO_LIB_ASCON_HASH_KUNIT_TEST) += ascon_hash_kunit.o
diff --git a/lib/crypto/tests/ascon_hash-testvecs.h b/lib/crypto/tests/ascon_hash-testvecs.h
new file mode 100644
index 000000000000..b5c0edcf61e6
--- /dev/null
+++ b/lib/crypto/tests/ascon_hash-testvecs.h
@@ -0,0 +1,235 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * The test vectors are generated using the Python reference implementation
+ * in https://github.com/meichlseder/pyascon/tree/master with messages from
+ * the method rand_bytes() in scripts/crypto/gen-hash-testvecs.py
+ */
+
+static const struct {
+	size_t data_len;
+	u8 digest[ASCON_HASH256_DIGEST_SIZE];
+} hash_testvecs[] = {
+	{
+		.data_len = 0,
+		.digest = {
+			0x0b, 0x3b, 0xe5, 0x85, 0x0f, 0x2f, 0x6b, 0x98,
+			0xca, 0xf2, 0x9f, 0x8f, 0xde, 0xa8, 0x9b, 0x64,
+			0xa1, 0xfa, 0x70, 0xaa, 0x24, 0x9b, 0x8f, 0x83,
+			0x9b, 0xd5, 0x3b, 0xaa, 0x30, 0x4d, 0x92, 0xb2,
+		},
+	},
+	{
+		.data_len = 1,
+		.digest = {
+			0xb9, 0xaa, 0x10, 0x34, 0x7a, 0x2e, 0x62, 0x01,
+			0x01, 0xcf, 0xbd, 0x55, 0x8e, 0x8d, 0x85, 0xda,
+			0x97, 0xe8, 0xd0, 0x5c, 0xbf, 0xf3, 0x19, 0xf7,
+			0x54, 0xcd, 0x32, 0xc0, 0xd0, 0x06, 0x72, 0x62,
+		},
+	},
+	{
+		.data_len = 2,
+		.digest = {
+			0xd9, 0x6b, 0x24, 0xe8, 0x0e, 0xaf, 0xd7, 0x43,
+			0x02, 0x76, 0x7e, 0xc3, 0x66, 0xfa, 0x15, 0x69,
+			0xe8, 0x86, 0x3b, 0xcd, 0x3b, 0xa4, 0xda, 0x77,
+			0xf5, 0xc0, 0x9d, 0x01, 0x8e, 0x9c, 0xae, 0xcd,
+		},
+	},
+	{
+		.data_len = 3,
+		.digest = {
+			0xaa, 0x09, 0xac, 0xf6, 0x0f, 0xa1, 0x54, 0xee,
+			0x5c, 0xe6, 0xf9, 0x44, 0xa8, 0x9f, 0xdb, 0x35,
+			0x68, 0x3b, 0x85, 0x15, 0x2f, 0x54, 0x51, 0x7d,
+			0x05, 0x1e, 0xff, 0x4c, 0x23, 0xa3, 0x46, 0x59,
+		},
+	},
+	{
+		.data_len = 16,
+		.digest = {
+			0xba, 0xc9, 0x62, 0x49, 0xba, 0x78, 0x92, 0x5f,
+			0xa8, 0xa9, 0xd3, 0x47, 0x60, 0x09, 0x1e, 0xdb,
+			0x23, 0x38, 0x2f, 0x43, 0x6a, 0x0f, 0x2f, 0xc8,
+			0x33, 0x9c, 0xdb, 0x9e, 0x38, 0x8f, 0xb0, 0x8a
+		},
+	},
+	{
+		.data_len = 32,
+		.digest = {
+			0x57, 0x6c, 0x66, 0xd5, 0xac, 0x36, 0xd2, 0xda,
+			0x14, 0x4f, 0x6e, 0x84, 0xab, 0xc9, 0xd5, 0x9e,
+			0xe4, 0xb2, 0x22, 0x4a, 0x8c, 0x3c, 0xf2, 0xf3,
+			0x2d, 0xbc, 0x6c, 0x96, 0xa0, 0xd4, 0xaf, 0xd3
+		},
+	},
+	{
+		.data_len = 48,
+		.digest = {
+			0x7e, 0x2e, 0xa5, 0x76, 0x69, 0xc9, 0xf1, 0x49,
+			0xb3, 0x89, 0x53, 0xca, 0x8f, 0x27, 0x6b, 0x89,
+			0xdc, 0x92, 0x5b, 0x48, 0x90, 0x8f, 0x19, 0x7c,
+			0xf2, 0x29, 0xa9, 0xde, 0x59, 0x9e, 0x81, 0x27
+		},
+	},
+	{
+		.data_len = 49,
+		.digest = {
+			0xb5, 0x75, 0xe9, 0xd8, 0x67, 0x75, 0xe2, 0x29,
+			0x3b, 0xff, 0x82, 0x14, 0x06, 0xcf, 0x00, 0x4a,
+			0xb2, 0x53, 0x01, 0x6e, 0x03, 0x86, 0xa6, 0x69,
+			0xe3, 0x64, 0x97, 0x56, 0x25, 0x5b, 0xec, 0x4e
+		},
+	},
+	{
+		.data_len = 63,
+		.digest = {
+			0xb3, 0x37, 0xbf, 0xff, 0xf8, 0x0b, 0x2b, 0xd7,
+			0x81, 0x4c, 0xce, 0x9f, 0x4b, 0xa9, 0x71, 0x3c,
+			0x93, 0x75, 0x04, 0x2d, 0x21, 0x66, 0x10, 0x58,
+			0x38, 0x4e, 0xf5, 0xd7, 0xeb, 0xb4, 0xae, 0x62
+		},
+	},
+	{
+		.data_len = 64,
+		.digest = {
+			0x57, 0xfc, 0x23, 0x3d, 0xf3, 0x48, 0xcc, 0xd2,
+			0x41, 0x39, 0xd8, 0x1c, 0x05, 0x5b, 0xa4, 0x63,
+			0x51, 0x0a, 0x77, 0x8e, 0xb5, 0x11, 0x17, 0xd6,
+			0xeb, 0x54, 0x15, 0xae, 0xb8, 0x2d, 0xd3, 0x5f
+		},
+	},
+	{
+		.data_len = 65,
+		.digest = {
+			0xae, 0x4c, 0xaa, 0x95, 0x86, 0x9c, 0xf2, 0x79,
+			0x57, 0x9a, 0xc9, 0x62, 0x8e, 0x60, 0xc4, 0xc8,
+			0x09, 0x3c, 0xc3, 0xbb, 0xdf, 0x35, 0x96, 0x51,
+			0x5d, 0x80, 0x9a, 0x00, 0x6a, 0xfb, 0xb6, 0xa2
+		},
+	},
+	{
+		.data_len = 127,
+		.digest = {
+			0x31, 0x4f, 0xfc, 0x1f, 0xb9, 0xc7, 0x30, 0x36,
+			0xc5, 0x5c, 0x1d, 0x85, 0x50, 0x4d, 0x96, 0x57,
+			0xeb, 0x75, 0xa4, 0xe0, 0x64, 0x89, 0x84, 0xa5,
+			0x34, 0x34, 0x6d, 0x0e, 0xbb, 0x74, 0x3a, 0x48
+		},
+	},
+	{
+		.data_len = 128,
+		.digest = {
+			0x2d, 0x39, 0xbb, 0x6d, 0xef, 0x31, 0x8f, 0x5a,
+			0xec, 0x5a, 0xf5, 0x86, 0xee, 0xec, 0x26, 0x1a,
+			0xc8, 0x38, 0x40, 0xdd, 0xf0, 0xa6, 0xf0, 0x5f,
+			0xf8, 0x92, 0x14, 0x23, 0x40, 0x48, 0x1b, 0x18
+		},
+	},
+	{
+		.data_len = 129,
+		.digest = {
+			0x97, 0xfc, 0xe5, 0xca, 0xa3, 0x62, 0xae, 0xa1,
+			0x3e, 0x62, 0xd6, 0x46, 0x55, 0x50, 0x26, 0xa7,
+			0x33, 0x36, 0x87, 0x68, 0xbc, 0x26, 0x70, 0x05,
+			0x49, 0x83, 0x9c, 0x68, 0x24, 0x1c, 0x3c, 0x44
+		},
+	},
+	{
+		.data_len = 256,
+		.digest = {
+			0x7d, 0x0c, 0x6d, 0xfb, 0x6b, 0x19, 0xc1, 0xe1,
+			0xa3, 0xd4, 0x2a, 0xae, 0x5a, 0xad, 0xaa, 0xc5,
+			0xeb, 0xa6, 0xb2, 0x72, 0xc5, 0x75, 0x9f, 0x27,
+			0x12, 0xd7, 0x7b, 0xb3, 0xc5, 0xb7, 0x2a, 0xe3
+		},
+	},
+	{
+		.data_len = 511,
+		.digest = {
+			0x32, 0x12, 0xb7, 0x28, 0xc2, 0xbc, 0xe7, 0x38,
+			0x8d, 0x0e, 0x52, 0x34, 0x1a, 0xbc, 0xb0, 0xde,
+			0x45, 0x2b, 0x08, 0x41, 0x23, 0xcf, 0x32, 0x7f,
+			0xd5, 0xa7, 0x2f, 0x99, 0xc6, 0xf6, 0x54, 0x33
+		},
+	},
+	{
+		.data_len = 513,
+		.digest = {
+			0x6b, 0x15, 0x49, 0x95, 0x0d, 0xfc, 0x26, 0x1d,
+			0xc5, 0x01, 0x55, 0x5e, 0x0c, 0x7c, 0x80, 0x57,
+			0xbe, 0xce, 0x04, 0x8e, 0x8e, 0x2e, 0x8a, 0xe8,
+			0xeb, 0x2e, 0x89, 0x4b, 0x6c, 0xea, 0x78, 0x71
+		},
+	},
+	{
+		.data_len = 1000,
+		.digest = {
+			0x13, 0x16, 0x77, 0xd5, 0x37, 0x7a, 0x8a, 0x02,
+			0x68, 0xd9, 0xd5, 0x51, 0xf4, 0x08, 0x7c, 0xe0,
+			0xad, 0xa1, 0x61, 0x17, 0x15, 0x57, 0xd8, 0xb6,
+			0x55, 0xee, 0xbb, 0x96, 0xcd, 0xdd, 0xd2, 0x0d
+		},
+	},
+	{
+		.data_len = 3333,
+		.digest = {
+			0x28, 0x15, 0xde, 0x05, 0x06, 0x68, 0xbc, 0xfe,
+			0xb1, 0x07, 0x72, 0x26, 0xa2, 0x31, 0x8f, 0xe0,
+			0xe9, 0x1a, 0x36, 0x00, 0x51, 0xd8, 0x85, 0xc9,
+			0xb9, 0x67, 0x55, 0x93, 0xe3, 0x02, 0x02, 0x5c
+		},
+	},
+	{
+		.data_len = 4096,
+		.digest = {
+			0x9b, 0x12, 0x0c, 0x12, 0xca, 0x22, 0x84, 0xd3,
+			0xc1, 0x5b, 0x0f, 0x2d, 0xee, 0x58, 0xc4, 0x67,
+			0x03, 0xf7, 0x6c, 0x28, 0xfa, 0xd1, 0x5d, 0x85,
+			0xd9, 0x4b, 0x4f, 0xb2, 0x8c, 0x36, 0x35, 0x53
+		},
+	},
+	{
+		.data_len = 4128,
+		.digest = {
+			0xe4, 0x4d, 0x10, 0xb1, 0x02, 0x62, 0x86, 0xca,
+			0x65, 0x0b, 0xcd, 0xe3, 0x62, 0x96, 0x67, 0xfc,
+			0x59, 0x12, 0x1d, 0x44, 0xed, 0x7b, 0xfb, 0x87,
+			0x82, 0xca, 0xdb, 0xcb, 0xe1, 0x93, 0xaa, 0xa6
+		},
+	},
+	{
+		.data_len = 4160,
+		.digest = {
+			0xe3, 0x03, 0x5e, 0x95, 0x5d, 0xf0, 0x6b, 0xe2,
+			0x30, 0x01, 0x56, 0xf2, 0x6b, 0x18, 0x15, 0xf4,
+			0xa0, 0x42, 0x33, 0xc4, 0x0b, 0xb9, 0xc2, 0xad,
+			0x98, 0xe7, 0x53, 0x2c, 0x8e, 0x8a, 0x1c, 0x02
+		},
+	},
+	{
+		.data_len = 4224,
+		.digest = {
+			0x22, 0x2b, 0x62, 0x2c, 0x21, 0x61, 0xd1, 0x23,
+			0x92, 0x9c, 0x8d, 0x07, 0x48, 0x4a, 0x25, 0x16,
+			0x34, 0x6f, 0x74, 0x3f, 0xbe, 0xf4, 0x7c, 0x1b,
+			0xea, 0xb9, 0x2a, 0x36, 0xc7, 0x3c, 0x1a, 0x32
+		},
+	},
+	{
+		.data_len = 16384,
+		.digest = {
+			0xe9, 0xe2, 0x04, 0xa1, 0x93, 0x8a, 0x7d, 0x6b,
+			0x18, 0x64, 0x38, 0xc5, 0x88, 0x41, 0x98, 0x68,
+			0xaf, 0xc3, 0xbb, 0xa5, 0x5f, 0x92, 0x12, 0xcb,
+			0x0e, 0x31, 0xdf, 0xe9, 0xc1, 0xfb, 0x5a, 0x23
+		},
+	},
+};
+
+static const u8 hash_testvec_consolidated[ASCON_HASH256_DIGEST_SIZE] = {
+	0x48, 0xae, 0x81, 0x92, 0x91, 0xc4, 0x32, 0xba,
+	0xe4, 0x96, 0x5d, 0xb7, 0xf1, 0xb6, 0xad, 0x10,
+	0xae, 0x09, 0x4a, 0x0b, 0xe1, 0xa7, 0x59, 0xa4,
+	0xfd, 0xcb, 0x47, 0x28, 0xfc, 0x0a, 0x34, 0x26,
+};
diff --git a/lib/crypto/tests/ascon_hash_kunit.c b/lib/crypto/tests/ascon_hash_kunit.c
new file mode 100644
index 000000000000..2ca15dbab2cb
--- /dev/null
+++ b/lib/crypto/tests/ascon_hash_kunit.c
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright 2025 Rusydi H. Makarim <rusydi.makarim@kriptograf.id>
+ */
+
+#include <crypto/ascon_hash.h>
+#include "ascon_hash-testvecs.h"
+
+#define HASH		ascon_hash256
+#define HASH_CTX	ascon_hash256_ctx
+#define HASH_SIZE	ASCON_HASH256_DIGEST_SIZE
+#define HASH_INIT	ascon_hash256_init
+#define HASH_UPDATE	ascon_hash256_update
+#define HASH_FINAL	ascon_hash256_final
+
+#include "hash-test-template.h"
+
+static struct kunit_case hash_test_cases[] = {
+	HASH_KUNIT_CASES,
+	KUNIT_CASE(benchmark_hash),
+	{},
+};
+
+static struct kunit_suite hash_test_suite = {
+	.name = "ascon_hash256",
+	.test_cases = hash_test_cases,
+	.suite_init = hash_suite_init,
+	.suite_exit = hash_suite_exit,
+};
+kunit_test_suite(hash_test_suite);
+
+MODULE_DESCRIPTION("KUnit tests and benchmark for Ascon-Hash256");
+MODULE_LICENSE("GPL");

-- 
2.52.0


^ permalink raw reply related	[flat|nested] 17+ messages in thread

* [PATCH 2/3] lib/crypto: Initial implementation of Ascon-Hash256
  2025-12-15  7:54 [PATCH 0/3] Implementation of Ascon-Hash256 Rusydi H. Makarim
  2025-12-15  7:54 ` [PATCH 1/3] lib/crypto: Add KUnit test vectors for Ascon-Hash256 Rusydi H. Makarim
@ 2025-12-15  7:54 ` Rusydi H. Makarim
  2025-12-15 23:01   ` kernel test robot
                     ` (3 more replies)
  2025-12-15  7:54 ` [PATCH 3/3] crypto: Crypto API " Rusydi H. Makarim
  2025-12-15 20:19 ` [PATCH 0/3] Implementation " Eric Biggers
  3 siblings, 4 replies; 17+ messages in thread
From: Rusydi H. Makarim @ 2025-12-15  7:54 UTC (permalink / raw)
  To: Herbert Xu, David S. Miller, Eric Biggers, Jason A. Donenfeld,
	Ard Biesheuvel
  Cc: linux-kernel, linux-crypto, Rusydi H. Makarim

	    initial implementation of Ascon-Hash256

Signed-off-by: Rusydi H. Makarim <rusydi.makarim@kriptograf.id>
---
 include/crypto/ascon_hash.h |   2 +-
 lib/crypto/Kconfig          |   8 +++
 lib/crypto/Makefile         |   5 ++
 lib/crypto/ascon_hash.c     | 154 ++++++++++++++++++++++++++++++++++++++++++++
 lib/crypto/hash_info.c      |   2 +
 5 files changed, 170 insertions(+), 1 deletion(-)

diff --git a/include/crypto/ascon_hash.h b/include/crypto/ascon_hash.h
index bb3561a745a9..c03a1414eec9 100644
--- a/include/crypto/ascon_hash.h
+++ b/include/crypto/ascon_hash.h
@@ -18,7 +18,7 @@
 
 /*
  * The standard of Ascon permutation in NIST SP 800-232 specifies 16 round
- * constants to accomodate potential functionality extensions in the future
+ * constants to accommodate potential functionality extensions in the future
  * (see page 2).
  */
 static const u64 ascon_p_rndc[] = {
diff --git a/lib/crypto/Kconfig b/lib/crypto/Kconfig
index 6871a41e5069..5f39ed6746de 100644
--- a/lib/crypto/Kconfig
+++ b/lib/crypto/Kconfig
@@ -223,6 +223,14 @@ config CRYPTO_LIB_SHA3_ARCH
 	default y if ARM64 && KERNEL_MODE_NEON
 	default y if S390
 
+config CRYPTO_LIB_ASCON_HASH
+	tristate
+	select CRYPTO_LIB_UTILS
+	help
+	  The Ascon-Hash library functions. Select this if your module uses any of
+	  the functions from <crypto/ascon_hash.h>
+
+
 config CRYPTO_LIB_SM3
 	tristate
 
diff --git a/lib/crypto/Makefile b/lib/crypto/Makefile
index 330ab65b29c4..6657ea3d8771 100644
--- a/lib/crypto/Makefile
+++ b/lib/crypto/Makefile
@@ -297,6 +297,11 @@ endif # CONFIG_CRYPTO_LIB_SHA3_ARCH
 
 ################################################################################
 
+obj-$(CONFIG_CRYPTO_LIB_ASCON_HASH) += libascon_hash.o
+libascon_hash-y := ascon_hash.o
+
+################################################################################
+
 obj-$(CONFIG_MPILIB) += mpi/
 
 obj-$(CONFIG_CRYPTO_SELFTESTS_FULL)		+= simd.o
diff --git a/lib/crypto/ascon_hash.c b/lib/crypto/ascon_hash.c
new file mode 100644
index 000000000000..e435a0e72195
--- /dev/null
+++ b/lib/crypto/ascon_hash.c
@@ -0,0 +1,154 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Ascon-Hash library functions
+ *
+ * Copyright (c) 2025 Rusydi H. Makarim <rusydi.makarim@kriptograf.id>
+ */
+
+#include <linux/module.h>
+#include <crypto/ascon_hash.h>
+#include <crypto/utils.h>
+
+
+static inline void ascon_round(u64 s[ASCON_STATE_WORDS], u64 C)
+{
+	u64 t[ASCON_STATE_WORDS];
+
+	// pC
+	s[2] ^= C;
+
+	// pS
+	s[0] ^= s[4];
+	s[4] ^= s[3];
+	s[2] ^= s[1];
+	t[0] = s[0] ^ (~s[1] & s[2]);
+	t[1] = s[1] ^ (~s[2] & s[3]);
+	t[2] = s[2] ^ (~s[3] & s[4]);
+	t[3] = s[3] ^ (~s[4] & s[0]);
+	t[4] = s[4] ^ (~s[0] & s[1]);
+	t[1] ^= t[0];
+	t[0] ^= t[4];
+	t[3] ^= t[2];
+	t[2] = ~t[2];
+
+	// pL
+	s[0] = t[0] ^ ror64(t[0], 19) ^ ror64(t[0], 28);
+	s[1] = t[1] ^ ror64(t[1], 61) ^ ror64(t[1], 39);
+	s[2] = t[2] ^ ror64(t[2],  1) ^ ror64(t[2], 6);
+	s[3] = t[3] ^ ror64(t[3], 10) ^ ror64(t[3], 17);
+	s[4] = t[4] ^ ror64(t[4],  7) ^ ror64(t[4], 41);
+}
+
+static inline void ascon_p12_generic(struct ascon_state *state)
+{
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(state->words); ++i)
+		state->native_words[i] = le64_to_cpu(state->words[i]);
+
+	for (i = 0; i < 12; ++i)
+		ascon_round(state->native_words, ascon_p_rndc[16 - 12 + i]);
+
+	for (i = 0; i < ARRAY_SIZE(state->words); ++i)
+		state->words[i] = cpu_to_le64(state->native_words[i]);
+}
+
+static void __maybe_unused ascon_hash256_absorb_blocks_generic(
+	struct ascon_state *state, const u8 *in, size_t nblocks)
+{
+	do {
+		for (size_t i = 0; i < ASCON_HASH256_BLOCK_SIZE; i += 8)
+			state->words[i / 8] ^= get_unaligned((__le64 *)&in[i]);
+		ascon_p12_generic(state);
+		in += ASCON_HASH256_BLOCK_SIZE;
+	} while (--nblocks);
+}
+
+#define ascon_p12 ascon_p12_generic
+#define ascon_hash256_absorb_blocks ascon_hash256_absorb_blocks_generic
+
+void ascon_hash256_init(struct ascon_hash256_ctx *asc_hash256_ctx)
+{
+	struct __ascon_hash_ctx *ctx = &asc_hash256_ctx->ctx;
+
+	ctx->state.words[0] = ASCON_HASH256_IV;
+	ctx->state.words[1] = 0;
+	ctx->state.words[2] = 0;
+	ctx->state.words[3] = 0;
+	ctx->state.words[4] = 0;
+	ctx->absorb_offset = 0;
+	ascon_p12(&ctx->state);
+}
+EXPORT_SYMBOL_GPL(ascon_hash256_init);
+
+void ascon_hash256_update(struct ascon_hash256_ctx *asc_hash256_ctx, const u8 *in,
+			    size_t in_len)
+{
+	struct __ascon_hash_ctx *ctx = &asc_hash256_ctx->ctx;
+	u8 absorb_offset = ctx->absorb_offset;
+
+	WARN_ON_ONCE(absorb_offset >= ASCON_HASH256_BLOCK_SIZE);
+
+	if (absorb_offset && absorb_offset + in_len >= ASCON_HASH256_BLOCK_SIZE) {
+		crypto_xor(&ctx->state.bytes[absorb_offset], in,
+			   ASCON_HASH256_BLOCK_SIZE - absorb_offset);
+		in += ASCON_HASH256_BLOCK_SIZE - absorb_offset;
+		in_len -= ASCON_HASH256_BLOCK_SIZE - absorb_offset;
+		ascon_p12(&ctx->state);
+		absorb_offset = 0;
+	}
+
+	if (in_len >= ASCON_HASH256_BLOCK_SIZE) {
+		size_t nblocks = in_len / ASCON_HASH256_BLOCK_SIZE;
+
+		ascon_hash256_absorb_blocks(&ctx->state, in, nblocks);
+		in += nblocks * ASCON_HASH256_BLOCK_SIZE;
+		in_len -= nblocks * ASCON_HASH256_BLOCK_SIZE;
+	}
+
+	if (in_len) {
+		crypto_xor(&ctx->state.bytes[absorb_offset], in, in_len);
+		absorb_offset += in_len;
+
+	}
+	ctx->absorb_offset = absorb_offset;
+}
+EXPORT_SYMBOL_GPL(ascon_hash256_update);
+
+void ascon_hash256_final(struct ascon_hash256_ctx *asc_hash256_ctx,
+			   u8 out[ASCON_HASH256_DIGEST_SIZE])
+{
+	struct __ascon_hash_ctx *ctx = &asc_hash256_ctx->ctx;
+
+	// padding
+	ctx->state.bytes[ctx->absorb_offset] ^= 0x01;
+	ascon_p12(&ctx->state);
+
+	// squeezing
+	size_t len = ASCON_HASH256_DIGEST_SIZE;
+
+	while (len > ASCON_HASH256_RATE) {
+		memcpy(out, ctx->state.bytes, ASCON_HASH256_RATE);
+		ascon_p12(&ctx->state);
+		out += ASCON_HASH256_RATE;
+		len -= ASCON_HASH256_RATE;
+	}
+	memcpy(out, ctx->state.bytes, ASCON_HASH256_RATE);
+	memzero_explicit(asc_hash256_ctx, sizeof(*asc_hash256_ctx));
+}
+EXPORT_SYMBOL_GPL(ascon_hash256_final);
+
+
+void ascon_hash256(const u8 *in, size_t in_len,
+		   u8 out[ASCON_HASH256_DIGEST_SIZE])
+{
+	struct ascon_hash256_ctx ctx;
+
+	ascon_hash256_init(&ctx);
+	ascon_hash256_update(&ctx, in, in_len);
+	ascon_hash256_final(&ctx, out);
+}
+EXPORT_SYMBOL_GPL(ascon_hash256);
+
+MODULE_DESCRIPTION("Ascon-Hash256 library functions");
+MODULE_LICENSE("GPL");
diff --git a/lib/crypto/hash_info.c b/lib/crypto/hash_info.c
index 9a467638c971..49ce182c6d08 100644
--- a/lib/crypto/hash_info.c
+++ b/lib/crypto/hash_info.c
@@ -32,6 +32,7 @@ const char *const hash_algo_name[HASH_ALGO__LAST] = {
 	[HASH_ALGO_SHA3_256]    = "sha3-256",
 	[HASH_ALGO_SHA3_384]    = "sha3-384",
 	[HASH_ALGO_SHA3_512]    = "sha3-512",
+	[HASH_ALGO_ASCON_HASH256] = "ascon-hash256",
 };
 EXPORT_SYMBOL_GPL(hash_algo_name);
 
@@ -59,5 +60,6 @@ const int hash_digest_size[HASH_ALGO__LAST] = {
 	[HASH_ALGO_SHA3_256]    = SHA3_256_DIGEST_SIZE,
 	[HASH_ALGO_SHA3_384]    = SHA3_384_DIGEST_SIZE,
 	[HASH_ALGO_SHA3_512]    = SHA3_512_DIGEST_SIZE,
+	[HASH_ALGO_ASCON_HASH256] = ASCON_HASH256_DIGEST_SIZE,
 };
 EXPORT_SYMBOL_GPL(hash_digest_size);

-- 
2.52.0


^ permalink raw reply related	[flat|nested] 17+ messages in thread

* [PATCH 3/3] crypto: Crypto API implementation of Ascon-Hash256
  2025-12-15  7:54 [PATCH 0/3] Implementation of Ascon-Hash256 Rusydi H. Makarim
  2025-12-15  7:54 ` [PATCH 1/3] lib/crypto: Add KUnit test vectors for Ascon-Hash256 Rusydi H. Makarim
  2025-12-15  7:54 ` [PATCH 2/3] lib/crypto: Initial implementation of Ascon-Hash256 Rusydi H. Makarim
@ 2025-12-15  7:54 ` Rusydi H. Makarim
  2025-12-15 20:19 ` [PATCH 0/3] Implementation " Eric Biggers
  3 siblings, 0 replies; 17+ messages in thread
From: Rusydi H. Makarim @ 2025-12-15  7:54 UTC (permalink / raw)
  To: Herbert Xu, David S. Miller, Eric Biggers, Jason A. Donenfeld,
	Ard Biesheuvel
  Cc: linux-kernel, linux-crypto, Rusydi H. Makarim

	This commit implements Ascon-Hash256 for Crypto API

Signed-off-by: Rusydi H. Makarim <rusydi.makarim@kriptograf.id>
---
 crypto/Kconfig      |  7 +++++
 crypto/Makefile     |  1 +
 crypto/ascon_hash.c | 86 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 94 insertions(+)

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 2e5b195b1b06..e671b5575535 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -1000,6 +1000,13 @@ config CRYPTO_SHA3
 	help
 	  SHA-3 secure hash algorithms (FIPS 202, ISO/IEC 10118-3)
 
+config CRYPTO_ASCON_HASH
+	tristate "Ascon-Hash"
+	select CRYPTO_HASH
+	select CRYPTO_LIB_ASCON_HASH
+	help
+	  Ascon-Hash secure hash algorithms (NIST SP 800-232)
+
 config CRYPTO_SM3_GENERIC
 	tristate "SM3 (ShangMi 3)"
 	select CRYPTO_HASH
diff --git a/crypto/Makefile b/crypto/Makefile
index 16a35649dd91..a697a92d2092 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -82,6 +82,7 @@ obj-$(CONFIG_CRYPTO_SHA3) += sha3.o
 obj-$(CONFIG_CRYPTO_SM3_GENERIC) += sm3_generic.o
 obj-$(CONFIG_CRYPTO_STREEBOG) += streebog_generic.o
 obj-$(CONFIG_CRYPTO_WP512) += wp512.o
+obj-$(CONFIG_CRYPTO_ASCON_HASH) += ascon_hash.o
 CFLAGS_wp512.o := $(call cc-option,-fno-schedule-insns)  # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79149
 obj-$(CONFIG_CRYPTO_BLAKE2B) += blake2b.o
 obj-$(CONFIG_CRYPTO_ECB) += ecb.o
diff --git a/crypto/ascon_hash.c b/crypto/ascon_hash.c
new file mode 100644
index 000000000000..2fa5e762fbc1
--- /dev/null
+++ b/crypto/ascon_hash.c
@@ -0,0 +1,86 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Crypto API support for Ascon-Hash256
+ * (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-232.pdf)
+ *
+ * Copyright (C) Rusydi H. Makarim <rusydi.makarim@kriptograf.id>
+ */
+
+#include <crypto/internal/hash.h>
+#include <crypto/ascon_hash.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+
+#define ASCON_HASH256_CTX(desc) ((struct ascon_hash256_ctx *)shash_desc_ctx(desc))
+
+static int crypto_ascon_hash256_init(struct shash_desc *desc)
+{
+	ascon_hash256_init(ASCON_HASH256_CTX(desc));
+	return 0;
+}
+
+static int crypto_ascon_hash256_update(struct shash_desc *desc, const u8 *data,
+				       unsigned int len)
+{
+	ascon_hash256_update(ASCON_HASH256_CTX(desc), data, len);
+	return 0;
+}
+
+static int crypto_ascon_hash256_final(struct shash_desc *desc, u8 *out)
+{
+	ascon_hash256_final(ASCON_HASH256_CTX(desc), out);
+	return 0;
+}
+
+static int crypto_ascon_hash256_digest(struct shash_desc *desc, const u8 *data,
+				       unsigned int len, u8 *out)
+{
+	ascon_hash256(data, len, out);
+	return 0;
+}
+
+static int crypto_ascon_hash256_export_core(struct shash_desc *desc, void *out)
+{
+	memcpy(out, ASCON_HASH256_CTX(desc), sizeof(struct ascon_hash256_ctx));
+	return 0;
+}
+
+static int crypto_ascon_hash256_import_core(struct shash_desc *desc,
+					    const void *in)
+{
+	memcpy(ASCON_HASH256_CTX(desc), in, sizeof(struct ascon_hash256_ctx));
+	return 0;
+}
+
+static struct shash_alg algs[] = { {
+	.digestsize = ASCON_HASH256_DIGEST_SIZE,
+	.init = crypto_ascon_hash256_init,
+	.update = crypto_ascon_hash256_update,
+	.final = crypto_ascon_hash256_final,
+	.digest = crypto_ascon_hash256_digest,
+	.export_core = crypto_ascon_hash256_export_core,
+	.import_core = crypto_ascon_hash256_import_core,
+	.descsize = sizeof(struct ascon_hash256_ctx),
+	.base.cra_name = "ascon-hash256",
+	.base.cra_driver_name = "ascon-hash256-lib",
+	.base.cra_blocksize = ASCON_HASH256_BLOCK_SIZE,
+	.base.cra_module = THIS_MODULE,
+} };
+
+static int __init crypto_ascon_hash256_mod_init(void)
+{
+	return crypto_register_shashes(algs, ARRAY_SIZE(algs));
+}
+module_init(crypto_ascon_hash256_mod_init);
+
+static void __exit crypto_ascon_hash256_mod_exit(void)
+{
+	crypto_unregister_shashes(algs, ARRAY_SIZE(algs));
+}
+module_exit(crypto_ascon_hash256_mod_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Crypto API support for Ascon-Hash256");
+
+MODULE_ALIAS_CRYPTO("ascon-hash256");
+MODULE_ALIAS_CRYPTO("ascon-hash256-lib");

-- 
2.52.0


^ permalink raw reply related	[flat|nested] 17+ messages in thread

* Re: [PATCH 0/3] Implementation of Ascon-Hash256
  2025-12-15  7:54 [PATCH 0/3] Implementation of Ascon-Hash256 Rusydi H. Makarim
                   ` (2 preceding siblings ...)
  2025-12-15  7:54 ` [PATCH 3/3] crypto: Crypto API " Rusydi H. Makarim
@ 2025-12-15 20:19 ` Eric Biggers
  2025-12-16  6:27   ` Rusydi H. Makarim
  3 siblings, 1 reply; 17+ messages in thread
From: Eric Biggers @ 2025-12-15 20:19 UTC (permalink / raw)
  To: Rusydi H. Makarim
  Cc: Herbert Xu, David S. Miller, Jason A. Donenfeld, Ard Biesheuvel,
	linux-kernel, linux-crypto

On Mon, Dec 15, 2025 at 02:54:33PM +0700, Rusydi H. Makarim wrote:
> This patch implements Ascon-Hash256. Ascon-Hash256 is a hash function as a part
> 	of the Ascon-Based Lightweight Cryptography Standards for Constrained Devices,
> 	published as NIST SP 800-232 (https://csrc.nist.gov/pubs/sp/800/232/final).
> 
> Signed-off-by: Rusydi H. Makarim <rusydi.makarim@kriptograf.id>

What is the use case for supporting this algorithm in the kernel?  Which
specific kernel subsystem will be using this algorithm, and why?

There's a significant maintainence cost to each supported algorithm.  So
if there's no in-kernel user, there's no need to add this.

- Eric

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 2/3] lib/crypto: Initial implementation of Ascon-Hash256
  2025-12-15  7:54 ` [PATCH 2/3] lib/crypto: Initial implementation of Ascon-Hash256 Rusydi H. Makarim
@ 2025-12-15 23:01   ` kernel test robot
  2025-12-20 15:34   ` kernel test robot
                     ` (2 subsequent siblings)
  3 siblings, 0 replies; 17+ messages in thread
From: kernel test robot @ 2025-12-15 23:01 UTC (permalink / raw)
  To: Rusydi H. Makarim, Herbert Xu, David S. Miller, Eric Biggers,
	Jason A. Donenfeld, Ard Biesheuvel
  Cc: llvm, oe-kbuild-all, netdev, linux-kernel, linux-crypto,
	Rusydi H. Makarim

Hi Rusydi,

kernel test robot noticed the following build errors:

[auto build test ERROR on ebiggers/libcrypto-next]
[also build test ERROR on ebiggers/libcrypto-fixes linus/master v6.19-rc1 next-20251215]
[cannot apply to herbert-cryptodev-2.6/master herbert-crypto-2.6/master]
[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/Rusydi-H-Makarim/lib-crypto-Initial-implementation-of-Ascon-Hash256/20251215-165442
base:   https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git libcrypto-next
patch link:    https://lore.kernel.org/r/20251215-ascon_hash256-v1-2-24ae735e571e%40kriptograf.id
patch subject: [PATCH 2/3] lib/crypto: Initial implementation of Ascon-Hash256
config: x86_64-kexec (https://download.01.org/0day-ci/archive/20251216/202512160656.DWMVkABi-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251216/202512160656.DWMVkABi-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/202512160656.DWMVkABi-lkp@intel.com/

All errors (new ones prefixed by >>):

>> lib/crypto/hash_info.c:35:3: error: use of undeclared identifier 'HASH_ALGO_ASCON_HASH256'
      35 |         [HASH_ALGO_ASCON_HASH256] = "ascon-hash256",
         |          ^
>> lib/crypto/hash_info.c:63:30: error: use of undeclared identifier 'ASCON_HASH256_DIGEST_SIZE'
      63 |         [HASH_ALGO_ASCON_HASH256] = ASCON_HASH256_DIGEST_SIZE,
         |                                     ^
   lib/crypto/hash_info.c:63:3: error: use of undeclared identifier 'HASH_ALGO_ASCON_HASH256'
      63 |         [HASH_ALGO_ASCON_HASH256] = ASCON_HASH256_DIGEST_SIZE,
         |          ^
   3 errors generated.


vim +/HASH_ALGO_ASCON_HASH256 +35 lib/crypto/hash_info.c

    10	
    11	const char *const hash_algo_name[HASH_ALGO__LAST] = {
    12		[HASH_ALGO_MD4]		= "md4",
    13		[HASH_ALGO_MD5]		= "md5",
    14		[HASH_ALGO_SHA1]	= "sha1",
    15		[HASH_ALGO_RIPE_MD_160]	= "rmd160",
    16		[HASH_ALGO_SHA256]	= "sha256",
    17		[HASH_ALGO_SHA384]	= "sha384",
    18		[HASH_ALGO_SHA512]	= "sha512",
    19		[HASH_ALGO_SHA224]	= "sha224",
    20		[HASH_ALGO_RIPE_MD_128]	= "rmd128",
    21		[HASH_ALGO_RIPE_MD_256]	= "rmd256",
    22		[HASH_ALGO_RIPE_MD_320]	= "rmd320",
    23		[HASH_ALGO_WP_256]	= "wp256",
    24		[HASH_ALGO_WP_384]	= "wp384",
    25		[HASH_ALGO_WP_512]	= "wp512",
    26		[HASH_ALGO_TGR_128]	= "tgr128",
    27		[HASH_ALGO_TGR_160]	= "tgr160",
    28		[HASH_ALGO_TGR_192]	= "tgr192",
    29		[HASH_ALGO_SM3_256]	= "sm3",
    30		[HASH_ALGO_STREEBOG_256] = "streebog256",
    31		[HASH_ALGO_STREEBOG_512] = "streebog512",
    32		[HASH_ALGO_SHA3_256]    = "sha3-256",
    33		[HASH_ALGO_SHA3_384]    = "sha3-384",
    34		[HASH_ALGO_SHA3_512]    = "sha3-512",
  > 35		[HASH_ALGO_ASCON_HASH256] = "ascon-hash256",
    36	};
    37	EXPORT_SYMBOL_GPL(hash_algo_name);
    38	
    39	const int hash_digest_size[HASH_ALGO__LAST] = {
    40		[HASH_ALGO_MD4]		= MD5_DIGEST_SIZE,
    41		[HASH_ALGO_MD5]		= MD5_DIGEST_SIZE,
    42		[HASH_ALGO_SHA1]	= SHA1_DIGEST_SIZE,
    43		[HASH_ALGO_RIPE_MD_160]	= RMD160_DIGEST_SIZE,
    44		[HASH_ALGO_SHA256]	= SHA256_DIGEST_SIZE,
    45		[HASH_ALGO_SHA384]	= SHA384_DIGEST_SIZE,
    46		[HASH_ALGO_SHA512]	= SHA512_DIGEST_SIZE,
    47		[HASH_ALGO_SHA224]	= SHA224_DIGEST_SIZE,
    48		[HASH_ALGO_RIPE_MD_128]	= RMD128_DIGEST_SIZE,
    49		[HASH_ALGO_RIPE_MD_256]	= RMD256_DIGEST_SIZE,
    50		[HASH_ALGO_RIPE_MD_320]	= RMD320_DIGEST_SIZE,
    51		[HASH_ALGO_WP_256]	= WP256_DIGEST_SIZE,
    52		[HASH_ALGO_WP_384]	= WP384_DIGEST_SIZE,
    53		[HASH_ALGO_WP_512]	= WP512_DIGEST_SIZE,
    54		[HASH_ALGO_TGR_128]	= TGR128_DIGEST_SIZE,
    55		[HASH_ALGO_TGR_160]	= TGR160_DIGEST_SIZE,
    56		[HASH_ALGO_TGR_192]	= TGR192_DIGEST_SIZE,
    57		[HASH_ALGO_SM3_256]	= SM3256_DIGEST_SIZE,
    58		[HASH_ALGO_STREEBOG_256] = STREEBOG256_DIGEST_SIZE,
    59		[HASH_ALGO_STREEBOG_512] = STREEBOG512_DIGEST_SIZE,
    60		[HASH_ALGO_SHA3_256]    = SHA3_256_DIGEST_SIZE,
    61		[HASH_ALGO_SHA3_384]    = SHA3_384_DIGEST_SIZE,
    62		[HASH_ALGO_SHA3_512]    = SHA3_512_DIGEST_SIZE,
  > 63		[HASH_ALGO_ASCON_HASH256] = ASCON_HASH256_DIGEST_SIZE,

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 0/3] Implementation of Ascon-Hash256
  2025-12-15 20:19 ` [PATCH 0/3] Implementation " Eric Biggers
@ 2025-12-16  6:27   ` Rusydi H. Makarim
  2025-12-16 18:02     ` Eric Biggers
  0 siblings, 1 reply; 17+ messages in thread
From: Rusydi H. Makarim @ 2025-12-16  6:27 UTC (permalink / raw)
  To: Eric Biggers
  Cc: Herbert Xu, David S. Miller, Jason A. Donenfeld, Ard Biesheuvel,
	linux-kernel, linux-crypto

On 2025-12-16 03:19, Eric Biggers wrote:
> On Mon, Dec 15, 2025 at 02:54:33PM +0700, Rusydi H. Makarim wrote:
>> This patch implements Ascon-Hash256. Ascon-Hash256 is a hash function 
>> as a part
>> 	of the Ascon-Based Lightweight Cryptography Standards for Constrained 
>> Devices,
>> 	published as NIST SP 800-232 
>> (https://csrc.nist.gov/pubs/sp/800/232/final).
>> 
>> Signed-off-by: Rusydi H. Makarim <rusydi.makarim@kriptograf.id>
> 
> What is the use case for supporting this algorithm in the kernel?  
> Which
> specific kernel subsystem will be using this algorithm, and why?

Ascon is a NIST standard (published in August 2025) for hashing, XOF, 
and AEAD in resource-constrained devices. Since it is a NIST standard, 
akin to AES and SHA-3, it will eventually find its way into the Linux 
kernel. It is only a matter of _when_ it becomes part of the kernel.

> There's a significant maintainence cost to each supported algorithm.  
> So
> if there's no in-kernel user, there's no need to add this.

While no direct in-kernel use as of now, adding this primitive now 
reduces the barrier for future adoption by kernel subsystems. 
Ascon-Hash256 specifically can serve as an alternative hash function to 
SHA-3 or Blake for existing use cases on devices that require more 
lightweight hashing.

The implementation of the standard starts with Ascon-Hash256 and is 
intentionally kept minimal to gather initial feedback. The final goal is 
to implement the complete NIST SP 800-232 in the kernel, which also 
includes Ascon-XOF128, Ascon-CXOF128, and Ascon-AEAD128.

> 
> - Eric

Best,
Rusydi

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 0/3] Implementation of Ascon-Hash256
  2025-12-16  6:27   ` Rusydi H. Makarim
@ 2025-12-16 18:02     ` Eric Biggers
       [not found]       ` <bb05699bc7922bb3668082367b4750f2@kriptograf.id>
  0 siblings, 1 reply; 17+ messages in thread
From: Eric Biggers @ 2025-12-16 18:02 UTC (permalink / raw)
  To: Rusydi H. Makarim
  Cc: Herbert Xu, David S. Miller, Jason A. Donenfeld, Ard Biesheuvel,
	linux-kernel, linux-crypto

On Tue, Dec 16, 2025 at 01:27:17PM +0700, Rusydi H. Makarim wrote:
> While no direct in-kernel use as of now

Thanks for confirming.  We only add algorithms when there is a real
user, so it's best to hold off on this for now.

- Eric

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 0/3] Implementation of Ascon-Hash256
       [not found]       ` <bb05699bc7922bb3668082367b4750f2@kriptograf.id>
@ 2025-12-17  4:06         ` Eric Biggers
  2025-12-31  9:20           ` Rusydi H. Makarim
  0 siblings, 1 reply; 17+ messages in thread
From: Eric Biggers @ 2025-12-17  4:06 UTC (permalink / raw)
  To: Rusydi H. Makarim
  Cc: Herbert Xu, David S. Miller, Jason A. Donenfeld, Ard Biesheuvel,
	linux-kernel, linux-crypto

On Wed, Dec 17, 2025 at 10:33:22AM +0700, Rusydi H. Makarim wrote:
> On 2025-12-17 01:02, Eric Biggers wrote:
> > On Tue, Dec 16, 2025 at 01:27:17PM +0700, Rusydi H. Makarim wrote:
> > > While no direct in-kernel use as of now
> > 
> > Thanks for confirming.  We only add algorithms when there is a real
> > user, so it's best to hold off on this for now.
> > 
> > - Eric
> 
> Rather than leaving this work idle, would it be better to move the
> implementation entirely into the Crypto API ?

No, that's actually the most problematic part because it would put it in
the name-based registry and become impossible to change later.

There's a large maintenance cost to supporting algorithms.  We've
learned this the hard way.  In the past the requirements to add new
algorithms to the kernel were much more relaxed, and as a result, the
Linux kernel community has ended up wasting lots of time maintaining
unused, unnecessary, or insecure code.

Just recently I removed a couple algorithms (keywrap and vmac).  Looking
back in more detail, there was actually never any use case presented for
their inclusion, and they were never used.  So all the effort spent
reviewing and maintaining that code was just wasted.  We could have just
never added them in the first place and saved tons of time.

So this is nothing about Ascon not being a good algorithm, but rather
we're just careful about adding unused code, as we don't want to repeat
past mistakes.  And as you've made clear, currently you'd like to add
the algorithm just for its own sake and there is no planned user --
which is concerning.  I'm not sure if this is a school project or what
not, but we don't really do that, sorry.  There has to be a clear
technical justification with an in-kernel use case.

- Eric

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 1/3] lib/crypto: Add KUnit test vectors for Ascon-Hash256
  2025-12-15  7:54 ` [PATCH 1/3] lib/crypto: Add KUnit test vectors for Ascon-Hash256 Rusydi H. Makarim
@ 2025-12-19  4:29   ` kernel test robot
  2025-12-22 17:11   ` kernel test robot
  1 sibling, 0 replies; 17+ messages in thread
From: kernel test robot @ 2025-12-19  4:29 UTC (permalink / raw)
  To: Rusydi H. Makarim, Herbert Xu, David S. Miller, Eric Biggers,
	Jason A. Donenfeld, Ard Biesheuvel
  Cc: oe-kbuild-all, netdev, linux-kernel, linux-crypto,
	Rusydi H. Makarim

Hi Rusydi,

kernel test robot noticed the following build warnings:

[auto build test WARNING on ebiggers/libcrypto-next]
[also build test WARNING on ebiggers/libcrypto-fixes linus/master v6.19-rc1 next-20251218]
[cannot apply to herbert-cryptodev-2.6/master herbert-crypto-2.6/master]
[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/Rusydi-H-Makarim/lib-crypto-Initial-implementation-of-Ascon-Hash256/20251215-165442
base:   https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git libcrypto-next
patch link:    https://lore.kernel.org/r/20251215-ascon_hash256-v1-1-24ae735e571e%40kriptograf.id
patch subject: [PATCH 1/3] lib/crypto: Add KUnit test vectors for Ascon-Hash256
config: parisc-randconfig-001-20251216 (https://download.01.org/0day-ci/archive/20251219/202512191115.8pVsYusz-lkp@intel.com/config)
compiler: hppa-linux-gcc (GCC) 11.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251219/202512191115.8pVsYusz-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/202512191115.8pVsYusz-lkp@intel.com/

All warnings (new ones prefixed by >>):

   In file included from lib/crypto/tests/ascon_hash_kunit.c:6:
>> include/crypto/ascon_hash.h:24:18: warning: 'ascon_p_rndc' defined but not used [-Wunused-const-variable=]
      24 | static const u64 ascon_p_rndc[] = {
         |                  ^~~~~~~~~~~~


vim +/ascon_p_rndc +24 include/crypto/ascon_hash.h

    18	
    19	/*
    20	 * The standard of Ascon permutation in NIST SP 800-232 specifies 16 round
    21	 * constants to accomodate potential functionality extensions in the future
    22	 * (see page 2).
    23	 */
  > 24	static const u64 ascon_p_rndc[] = {
    25		0x000000000000003cULL, 0x000000000000002dULL, 0x000000000000001eULL,
    26		0x000000000000000fULL, 0x00000000000000f0ULL, 0x00000000000000e1ULL,
    27		0x00000000000000d2ULL, 0x00000000000000c3ULL, 0x00000000000000b4ULL,
    28		0x00000000000000a5ULL, 0x0000000000000096ULL, 0x0000000000000087ULL,
    29		0x0000000000000078ULL, 0x0000000000000069ULL, 0x000000000000005aULL,
    30		0x000000000000004bULL,
    31	};
    32	

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 2/3] lib/crypto: Initial implementation of Ascon-Hash256
  2025-12-15  7:54 ` [PATCH 2/3] lib/crypto: Initial implementation of Ascon-Hash256 Rusydi H. Makarim
  2025-12-15 23:01   ` kernel test robot
@ 2025-12-20 15:34   ` kernel test robot
  2025-12-20 16:20   ` kernel test robot
  2025-12-22 17:41   ` kernel test robot
  3 siblings, 0 replies; 17+ messages in thread
From: kernel test robot @ 2025-12-20 15:34 UTC (permalink / raw)
  To: Rusydi H. Makarim, Herbert Xu, David S. Miller, Eric Biggers,
	Jason A. Donenfeld, Ard Biesheuvel
  Cc: oe-kbuild-all, netdev, linux-kernel, linux-crypto,
	Rusydi H. Makarim

Hi Rusydi,

kernel test robot noticed the following build errors:

[auto build test ERROR on 92de2d349e02c2dd96d8d1b7016cc78cf80fc085]

url:    https://github.com/intel-lab-lkp/linux/commits/Rusydi-H-Makarim/lib-crypto-Add-KUnit-test-vectors-for-Ascon-Hash256/20251215-215114
base:   92de2d349e02c2dd96d8d1b7016cc78cf80fc085
patch link:    https://lore.kernel.org/r/20251215-ascon_hash256-v1-2-24ae735e571e%40kriptograf.id
patch subject: [PATCH 2/3] lib/crypto: Initial implementation of Ascon-Hash256
config: x86_64-rhel-9.4-ltp (https://download.01.org/0day-ci/archive/20251220/202512201605.QLcE0Qu7-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/20251220/202512201605.QLcE0Qu7-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/202512201605.QLcE0Qu7-lkp@intel.com/

All errors (new ones prefixed by >>):

>> lib/crypto/hash_info.c:35:10: error: 'HASH_ALGO_ASCON_HASH256' undeclared here (not in a function); did you mean 'HASH_ALGO_SHA3_256'?
      35 |         [HASH_ALGO_ASCON_HASH256] = "ascon-hash256",
         |          ^~~~~~~~~~~~~~~~~~~~~~~
         |          HASH_ALGO_SHA3_256
>> lib/crypto/hash_info.c:35:10: error: array index in initializer not of integer type
   lib/crypto/hash_info.c:35:10: note: (near initialization for 'hash_algo_name')
   lib/crypto/hash_info.c:35:37: warning: excess elements in array initializer
      35 |         [HASH_ALGO_ASCON_HASH256] = "ascon-hash256",
         |                                     ^~~~~~~~~~~~~~~
   lib/crypto/hash_info.c:35:37: note: (near initialization for 'hash_algo_name')
   lib/crypto/hash_info.c:63:10: error: array index in initializer not of integer type
      63 |         [HASH_ALGO_ASCON_HASH256] = ASCON_HASH256_DIGEST_SIZE,
         |          ^~~~~~~~~~~~~~~~~~~~~~~
   lib/crypto/hash_info.c:63:10: note: (near initialization for 'hash_digest_size')
>> lib/crypto/hash_info.c:63:37: error: 'ASCON_HASH256_DIGEST_SIZE' undeclared here (not in a function); did you mean 'SHA256_DIGEST_SIZE'?
      63 |         [HASH_ALGO_ASCON_HASH256] = ASCON_HASH256_DIGEST_SIZE,
         |                                     ^~~~~~~~~~~~~~~~~~~~~~~~~
         |                                     SHA256_DIGEST_SIZE
   lib/crypto/hash_info.c:63:37: warning: excess elements in array initializer
   lib/crypto/hash_info.c:63:37: note: (near initialization for 'hash_digest_size')


vim +35 lib/crypto/hash_info.c

    10	
    11	const char *const hash_algo_name[HASH_ALGO__LAST] = {
    12		[HASH_ALGO_MD4]		= "md4",
    13		[HASH_ALGO_MD5]		= "md5",
    14		[HASH_ALGO_SHA1]	= "sha1",
    15		[HASH_ALGO_RIPE_MD_160]	= "rmd160",
    16		[HASH_ALGO_SHA256]	= "sha256",
    17		[HASH_ALGO_SHA384]	= "sha384",
    18		[HASH_ALGO_SHA512]	= "sha512",
    19		[HASH_ALGO_SHA224]	= "sha224",
    20		[HASH_ALGO_RIPE_MD_128]	= "rmd128",
    21		[HASH_ALGO_RIPE_MD_256]	= "rmd256",
    22		[HASH_ALGO_RIPE_MD_320]	= "rmd320",
    23		[HASH_ALGO_WP_256]	= "wp256",
    24		[HASH_ALGO_WP_384]	= "wp384",
    25		[HASH_ALGO_WP_512]	= "wp512",
    26		[HASH_ALGO_TGR_128]	= "tgr128",
    27		[HASH_ALGO_TGR_160]	= "tgr160",
    28		[HASH_ALGO_TGR_192]	= "tgr192",
    29		[HASH_ALGO_SM3_256]	= "sm3",
    30		[HASH_ALGO_STREEBOG_256] = "streebog256",
    31		[HASH_ALGO_STREEBOG_512] = "streebog512",
    32		[HASH_ALGO_SHA3_256]    = "sha3-256",
    33		[HASH_ALGO_SHA3_384]    = "sha3-384",
    34		[HASH_ALGO_SHA3_512]    = "sha3-512",
  > 35		[HASH_ALGO_ASCON_HASH256] = "ascon-hash256",
    36	};
    37	EXPORT_SYMBOL_GPL(hash_algo_name);
    38	
    39	const int hash_digest_size[HASH_ALGO__LAST] = {
    40		[HASH_ALGO_MD4]		= MD5_DIGEST_SIZE,
    41		[HASH_ALGO_MD5]		= MD5_DIGEST_SIZE,
    42		[HASH_ALGO_SHA1]	= SHA1_DIGEST_SIZE,
    43		[HASH_ALGO_RIPE_MD_160]	= RMD160_DIGEST_SIZE,
    44		[HASH_ALGO_SHA256]	= SHA256_DIGEST_SIZE,
    45		[HASH_ALGO_SHA384]	= SHA384_DIGEST_SIZE,
    46		[HASH_ALGO_SHA512]	= SHA512_DIGEST_SIZE,
    47		[HASH_ALGO_SHA224]	= SHA224_DIGEST_SIZE,
    48		[HASH_ALGO_RIPE_MD_128]	= RMD128_DIGEST_SIZE,
    49		[HASH_ALGO_RIPE_MD_256]	= RMD256_DIGEST_SIZE,
    50		[HASH_ALGO_RIPE_MD_320]	= RMD320_DIGEST_SIZE,
    51		[HASH_ALGO_WP_256]	= WP256_DIGEST_SIZE,
    52		[HASH_ALGO_WP_384]	= WP384_DIGEST_SIZE,
    53		[HASH_ALGO_WP_512]	= WP512_DIGEST_SIZE,
    54		[HASH_ALGO_TGR_128]	= TGR128_DIGEST_SIZE,
    55		[HASH_ALGO_TGR_160]	= TGR160_DIGEST_SIZE,
    56		[HASH_ALGO_TGR_192]	= TGR192_DIGEST_SIZE,
    57		[HASH_ALGO_SM3_256]	= SM3256_DIGEST_SIZE,
    58		[HASH_ALGO_STREEBOG_256] = STREEBOG256_DIGEST_SIZE,
    59		[HASH_ALGO_STREEBOG_512] = STREEBOG512_DIGEST_SIZE,
    60		[HASH_ALGO_SHA3_256]    = SHA3_256_DIGEST_SIZE,
    61		[HASH_ALGO_SHA3_384]    = SHA3_384_DIGEST_SIZE,
    62		[HASH_ALGO_SHA3_512]    = SHA3_512_DIGEST_SIZE,
  > 63		[HASH_ALGO_ASCON_HASH256] = ASCON_HASH256_DIGEST_SIZE,

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 2/3] lib/crypto: Initial implementation of Ascon-Hash256
  2025-12-15  7:54 ` [PATCH 2/3] lib/crypto: Initial implementation of Ascon-Hash256 Rusydi H. Makarim
  2025-12-15 23:01   ` kernel test robot
  2025-12-20 15:34   ` kernel test robot
@ 2025-12-20 16:20   ` kernel test robot
  2025-12-22 17:41   ` kernel test robot
  3 siblings, 0 replies; 17+ messages in thread
From: kernel test robot @ 2025-12-20 16:20 UTC (permalink / raw)
  To: Rusydi H. Makarim, Herbert Xu, David S. Miller, Eric Biggers,
	Jason A. Donenfeld, Ard Biesheuvel
  Cc: llvm, oe-kbuild-all, netdev, linux-kernel, linux-crypto,
	Rusydi H. Makarim

Hi Rusydi,

kernel test robot noticed the following build errors:

[auto build test ERROR on 92de2d349e02c2dd96d8d1b7016cc78cf80fc085]

url:    https://github.com/intel-lab-lkp/linux/commits/Rusydi-H-Makarim/lib-crypto-Add-KUnit-test-vectors-for-Ascon-Hash256/20251215-215114
base:   92de2d349e02c2dd96d8d1b7016cc78cf80fc085
patch link:    https://lore.kernel.org/r/20251215-ascon_hash256-v1-2-24ae735e571e%40kriptograf.id
patch subject: [PATCH 2/3] lib/crypto: Initial implementation of Ascon-Hash256
config: x86_64-kexec (https://download.01.org/0day-ci/archive/20251221/202512210037.K5OAaoVa-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251221/202512210037.K5OAaoVa-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/202512210037.K5OAaoVa-lkp@intel.com/

All errors (new ones prefixed by >>):

>> lib/crypto/hash_info.c:35:3: error: use of undeclared identifier 'HASH_ALGO_ASCON_HASH256'
      35 |         [HASH_ALGO_ASCON_HASH256] = "ascon-hash256",
         |          ^
>> lib/crypto/hash_info.c:63:30: error: use of undeclared identifier 'ASCON_HASH256_DIGEST_SIZE'
      63 |         [HASH_ALGO_ASCON_HASH256] = ASCON_HASH256_DIGEST_SIZE,
         |                                     ^
   lib/crypto/hash_info.c:63:3: error: use of undeclared identifier 'HASH_ALGO_ASCON_HASH256'
      63 |         [HASH_ALGO_ASCON_HASH256] = ASCON_HASH256_DIGEST_SIZE,
         |          ^
   3 errors generated.


vim +/HASH_ALGO_ASCON_HASH256 +35 lib/crypto/hash_info.c

    10	
    11	const char *const hash_algo_name[HASH_ALGO__LAST] = {
    12		[HASH_ALGO_MD4]		= "md4",
    13		[HASH_ALGO_MD5]		= "md5",
    14		[HASH_ALGO_SHA1]	= "sha1",
    15		[HASH_ALGO_RIPE_MD_160]	= "rmd160",
    16		[HASH_ALGO_SHA256]	= "sha256",
    17		[HASH_ALGO_SHA384]	= "sha384",
    18		[HASH_ALGO_SHA512]	= "sha512",
    19		[HASH_ALGO_SHA224]	= "sha224",
    20		[HASH_ALGO_RIPE_MD_128]	= "rmd128",
    21		[HASH_ALGO_RIPE_MD_256]	= "rmd256",
    22		[HASH_ALGO_RIPE_MD_320]	= "rmd320",
    23		[HASH_ALGO_WP_256]	= "wp256",
    24		[HASH_ALGO_WP_384]	= "wp384",
    25		[HASH_ALGO_WP_512]	= "wp512",
    26		[HASH_ALGO_TGR_128]	= "tgr128",
    27		[HASH_ALGO_TGR_160]	= "tgr160",
    28		[HASH_ALGO_TGR_192]	= "tgr192",
    29		[HASH_ALGO_SM3_256]	= "sm3",
    30		[HASH_ALGO_STREEBOG_256] = "streebog256",
    31		[HASH_ALGO_STREEBOG_512] = "streebog512",
    32		[HASH_ALGO_SHA3_256]    = "sha3-256",
    33		[HASH_ALGO_SHA3_384]    = "sha3-384",
    34		[HASH_ALGO_SHA3_512]    = "sha3-512",
  > 35		[HASH_ALGO_ASCON_HASH256] = "ascon-hash256",
    36	};
    37	EXPORT_SYMBOL_GPL(hash_algo_name);
    38	
    39	const int hash_digest_size[HASH_ALGO__LAST] = {
    40		[HASH_ALGO_MD4]		= MD5_DIGEST_SIZE,
    41		[HASH_ALGO_MD5]		= MD5_DIGEST_SIZE,
    42		[HASH_ALGO_SHA1]	= SHA1_DIGEST_SIZE,
    43		[HASH_ALGO_RIPE_MD_160]	= RMD160_DIGEST_SIZE,
    44		[HASH_ALGO_SHA256]	= SHA256_DIGEST_SIZE,
    45		[HASH_ALGO_SHA384]	= SHA384_DIGEST_SIZE,
    46		[HASH_ALGO_SHA512]	= SHA512_DIGEST_SIZE,
    47		[HASH_ALGO_SHA224]	= SHA224_DIGEST_SIZE,
    48		[HASH_ALGO_RIPE_MD_128]	= RMD128_DIGEST_SIZE,
    49		[HASH_ALGO_RIPE_MD_256]	= RMD256_DIGEST_SIZE,
    50		[HASH_ALGO_RIPE_MD_320]	= RMD320_DIGEST_SIZE,
    51		[HASH_ALGO_WP_256]	= WP256_DIGEST_SIZE,
    52		[HASH_ALGO_WP_384]	= WP384_DIGEST_SIZE,
    53		[HASH_ALGO_WP_512]	= WP512_DIGEST_SIZE,
    54		[HASH_ALGO_TGR_128]	= TGR128_DIGEST_SIZE,
    55		[HASH_ALGO_TGR_160]	= TGR160_DIGEST_SIZE,
    56		[HASH_ALGO_TGR_192]	= TGR192_DIGEST_SIZE,
    57		[HASH_ALGO_SM3_256]	= SM3256_DIGEST_SIZE,
    58		[HASH_ALGO_STREEBOG_256] = STREEBOG256_DIGEST_SIZE,
    59		[HASH_ALGO_STREEBOG_512] = STREEBOG512_DIGEST_SIZE,
    60		[HASH_ALGO_SHA3_256]    = SHA3_256_DIGEST_SIZE,
    61		[HASH_ALGO_SHA3_384]    = SHA3_384_DIGEST_SIZE,
    62		[HASH_ALGO_SHA3_512]    = SHA3_512_DIGEST_SIZE,
  > 63		[HASH_ALGO_ASCON_HASH256] = ASCON_HASH256_DIGEST_SIZE,

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 1/3] lib/crypto: Add KUnit test vectors for Ascon-Hash256
  2025-12-15  7:54 ` [PATCH 1/3] lib/crypto: Add KUnit test vectors for Ascon-Hash256 Rusydi H. Makarim
  2025-12-19  4:29   ` kernel test robot
@ 2025-12-22 17:11   ` kernel test robot
  1 sibling, 0 replies; 17+ messages in thread
From: kernel test robot @ 2025-12-22 17:11 UTC (permalink / raw)
  To: Rusydi H. Makarim, Herbert Xu, David S. Miller, Eric Biggers,
	Jason A. Donenfeld, Ard Biesheuvel
  Cc: oe-kbuild-all, netdev, linux-kernel, linux-crypto,
	Rusydi H. Makarim

Hi Rusydi,

kernel test robot noticed the following build warnings:

[auto build test WARNING on 92de2d349e02c2dd96d8d1b7016cc78cf80fc085]

url:    https://github.com/intel-lab-lkp/linux/commits/Rusydi-H-Makarim/lib-crypto-Add-KUnit-test-vectors-for-Ascon-Hash256/20251215-215114
base:   92de2d349e02c2dd96d8d1b7016cc78cf80fc085
patch link:    https://lore.kernel.org/r/20251215-ascon_hash256-v1-1-24ae735e571e%40kriptograf.id
patch subject: [PATCH 1/3] lib/crypto: Add KUnit test vectors for Ascon-Hash256
config: x86_64-rhel-9.4-kunit (https://download.01.org/0day-ci/archive/20251222/202512221855.nLchuL2R-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/20251222/202512221855.nLchuL2R-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/202512221855.nLchuL2R-lkp@intel.com/

All warnings (new ones prefixed by >>):

   In file included from lib/crypto/tests/ascon_hash_kunit.c:6:
>> include/crypto/ascon_hash.h:24:18: warning: 'ascon_p_rndc' defined but not used [-Wunused-const-variable=]
      24 | static const u64 ascon_p_rndc[] = {
         |                  ^~~~~~~~~~~~


vim +/ascon_p_rndc +24 include/crypto/ascon_hash.h

    18	
    19	/*
    20	 * The standard of Ascon permutation in NIST SP 800-232 specifies 16 round
    21	 * constants to accomodate potential functionality extensions in the future
    22	 * (see page 2).
    23	 */
  > 24	static const u64 ascon_p_rndc[] = {
    25		0x000000000000003cULL, 0x000000000000002dULL, 0x000000000000001eULL,
    26		0x000000000000000fULL, 0x00000000000000f0ULL, 0x00000000000000e1ULL,
    27		0x00000000000000d2ULL, 0x00000000000000c3ULL, 0x00000000000000b4ULL,
    28		0x00000000000000a5ULL, 0x0000000000000096ULL, 0x0000000000000087ULL,
    29		0x0000000000000078ULL, 0x0000000000000069ULL, 0x000000000000005aULL,
    30		0x000000000000004bULL,
    31	};
    32	

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 2/3] lib/crypto: Initial implementation of Ascon-Hash256
  2025-12-15  7:54 ` [PATCH 2/3] lib/crypto: Initial implementation of Ascon-Hash256 Rusydi H. Makarim
                     ` (2 preceding siblings ...)
  2025-12-20 16:20   ` kernel test robot
@ 2025-12-22 17:41   ` kernel test robot
  3 siblings, 0 replies; 17+ messages in thread
From: kernel test robot @ 2025-12-22 17:41 UTC (permalink / raw)
  To: Rusydi H. Makarim, Herbert Xu, David S. Miller, Eric Biggers,
	Jason A. Donenfeld, Ard Biesheuvel
  Cc: oe-kbuild-all, netdev, linux-kernel, linux-crypto,
	Rusydi H. Makarim

Hi Rusydi,

kernel test robot noticed the following build errors:

[auto build test ERROR on 92de2d349e02c2dd96d8d1b7016cc78cf80fc085]

url:    https://github.com/intel-lab-lkp/linux/commits/Rusydi-H-Makarim/lib-crypto-Add-KUnit-test-vectors-for-Ascon-Hash256/20251215-215114
base:   92de2d349e02c2dd96d8d1b7016cc78cf80fc085
patch link:    https://lore.kernel.org/r/20251215-ascon_hash256-v1-2-24ae735e571e%40kriptograf.id
patch subject: [PATCH 2/3] lib/crypto: Initial implementation of Ascon-Hash256
config: x86_64-rhel-9.4 (https://download.01.org/0day-ci/archive/20251222/202512221849.wfygt22c-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/20251222/202512221849.wfygt22c-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/202512221849.wfygt22c-lkp@intel.com/

All error/warnings (new ones prefixed by >>):

>> lib/crypto/hash_info.c:35:10: error: 'HASH_ALGO_ASCON_HASH256' undeclared here (not in a function); did you mean 'HASH_ALGO_SHA3_256'?
      35 |         [HASH_ALGO_ASCON_HASH256] = "ascon-hash256",
         |          ^~~~~~~~~~~~~~~~~~~~~~~
         |          HASH_ALGO_SHA3_256
>> lib/crypto/hash_info.c:35:10: error: array index in initializer not of integer type
   lib/crypto/hash_info.c:35:10: note: (near initialization for 'hash_algo_name')
>> lib/crypto/hash_info.c:35:37: warning: excess elements in array initializer
      35 |         [HASH_ALGO_ASCON_HASH256] = "ascon-hash256",
         |                                     ^~~~~~~~~~~~~~~
   lib/crypto/hash_info.c:35:37: note: (near initialization for 'hash_algo_name')
   lib/crypto/hash_info.c:63:10: error: array index in initializer not of integer type
      63 |         [HASH_ALGO_ASCON_HASH256] = ASCON_HASH256_DIGEST_SIZE,
         |          ^~~~~~~~~~~~~~~~~~~~~~~
   lib/crypto/hash_info.c:63:10: note: (near initialization for 'hash_digest_size')
>> lib/crypto/hash_info.c:63:37: error: 'ASCON_HASH256_DIGEST_SIZE' undeclared here (not in a function); did you mean 'SHA256_DIGEST_SIZE'?
      63 |         [HASH_ALGO_ASCON_HASH256] = ASCON_HASH256_DIGEST_SIZE,
         |                                     ^~~~~~~~~~~~~~~~~~~~~~~~~
         |                                     SHA256_DIGEST_SIZE
   lib/crypto/hash_info.c:63:37: warning: excess elements in array initializer
   lib/crypto/hash_info.c:63:37: note: (near initialization for 'hash_digest_size')


vim +35 lib/crypto/hash_info.c

    10	
    11	const char *const hash_algo_name[HASH_ALGO__LAST] = {
    12		[HASH_ALGO_MD4]		= "md4",
    13		[HASH_ALGO_MD5]		= "md5",
    14		[HASH_ALGO_SHA1]	= "sha1",
    15		[HASH_ALGO_RIPE_MD_160]	= "rmd160",
    16		[HASH_ALGO_SHA256]	= "sha256",
    17		[HASH_ALGO_SHA384]	= "sha384",
    18		[HASH_ALGO_SHA512]	= "sha512",
    19		[HASH_ALGO_SHA224]	= "sha224",
    20		[HASH_ALGO_RIPE_MD_128]	= "rmd128",
    21		[HASH_ALGO_RIPE_MD_256]	= "rmd256",
    22		[HASH_ALGO_RIPE_MD_320]	= "rmd320",
    23		[HASH_ALGO_WP_256]	= "wp256",
    24		[HASH_ALGO_WP_384]	= "wp384",
    25		[HASH_ALGO_WP_512]	= "wp512",
    26		[HASH_ALGO_TGR_128]	= "tgr128",
    27		[HASH_ALGO_TGR_160]	= "tgr160",
    28		[HASH_ALGO_TGR_192]	= "tgr192",
    29		[HASH_ALGO_SM3_256]	= "sm3",
    30		[HASH_ALGO_STREEBOG_256] = "streebog256",
    31		[HASH_ALGO_STREEBOG_512] = "streebog512",
    32		[HASH_ALGO_SHA3_256]    = "sha3-256",
    33		[HASH_ALGO_SHA3_384]    = "sha3-384",
    34		[HASH_ALGO_SHA3_512]    = "sha3-512",
  > 35		[HASH_ALGO_ASCON_HASH256] = "ascon-hash256",
    36	};
    37	EXPORT_SYMBOL_GPL(hash_algo_name);
    38	
    39	const int hash_digest_size[HASH_ALGO__LAST] = {
    40		[HASH_ALGO_MD4]		= MD5_DIGEST_SIZE,
    41		[HASH_ALGO_MD5]		= MD5_DIGEST_SIZE,
    42		[HASH_ALGO_SHA1]	= SHA1_DIGEST_SIZE,
    43		[HASH_ALGO_RIPE_MD_160]	= RMD160_DIGEST_SIZE,
    44		[HASH_ALGO_SHA256]	= SHA256_DIGEST_SIZE,
    45		[HASH_ALGO_SHA384]	= SHA384_DIGEST_SIZE,
    46		[HASH_ALGO_SHA512]	= SHA512_DIGEST_SIZE,
    47		[HASH_ALGO_SHA224]	= SHA224_DIGEST_SIZE,
    48		[HASH_ALGO_RIPE_MD_128]	= RMD128_DIGEST_SIZE,
    49		[HASH_ALGO_RIPE_MD_256]	= RMD256_DIGEST_SIZE,
    50		[HASH_ALGO_RIPE_MD_320]	= RMD320_DIGEST_SIZE,
    51		[HASH_ALGO_WP_256]	= WP256_DIGEST_SIZE,
    52		[HASH_ALGO_WP_384]	= WP384_DIGEST_SIZE,
    53		[HASH_ALGO_WP_512]	= WP512_DIGEST_SIZE,
    54		[HASH_ALGO_TGR_128]	= TGR128_DIGEST_SIZE,
    55		[HASH_ALGO_TGR_160]	= TGR160_DIGEST_SIZE,
    56		[HASH_ALGO_TGR_192]	= TGR192_DIGEST_SIZE,
    57		[HASH_ALGO_SM3_256]	= SM3256_DIGEST_SIZE,
    58		[HASH_ALGO_STREEBOG_256] = STREEBOG256_DIGEST_SIZE,
    59		[HASH_ALGO_STREEBOG_512] = STREEBOG512_DIGEST_SIZE,
    60		[HASH_ALGO_SHA3_256]    = SHA3_256_DIGEST_SIZE,
    61		[HASH_ALGO_SHA3_384]    = SHA3_384_DIGEST_SIZE,
    62		[HASH_ALGO_SHA3_512]    = SHA3_512_DIGEST_SIZE,
  > 63		[HASH_ALGO_ASCON_HASH256] = ASCON_HASH256_DIGEST_SIZE,

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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 0/3] Implementation of Ascon-Hash256
  2025-12-17  4:06         ` Eric Biggers
@ 2025-12-31  9:20           ` Rusydi H. Makarim
  2026-01-01 21:06             ` Eric Biggers
  0 siblings, 1 reply; 17+ messages in thread
From: Rusydi H. Makarim @ 2025-12-31  9:20 UTC (permalink / raw)
  To: Eric Biggers
  Cc: Herbert Xu, David S. Miller, Jason A. Donenfeld, Ard Biesheuvel,
	linux-kernel, linux-crypto

On Tue, Dec 16, 2025 at 08:06:17PM -0800, Eric Biggers wrote:
> On Wed, Dec 17, 2025 at 10:33:22AM +0700, Rusydi H. Makarim wrote:
> > On 2025-12-17 01:02, Eric Biggers wrote:
> > > On Tue, Dec 16, 2025 at 01:27:17PM +0700, Rusydi H. Makarim wrote:
> > > > While no direct in-kernel use as of now
> > > 
> > > Thanks for confirming.  We only add algorithms when there is a real
> > > user, so it's best to hold off on this for now.
> > > 
> > > - Eric
> > 
> > Rather than leaving this work idle, would it be better to move the
> > implementation entirely into the Crypto API ?
> 
> No, that's actually the most problematic part because it would put it in
> the name-based registry and become impossible to change later.
> 
> There's a large maintenance cost to supporting algorithms.  We've
> learned this the hard way.  In the past the requirements to add new
> algorithms to the kernel were much more relaxed, and as a result, the
> Linux kernel community has ended up wasting lots of time maintaining
> unused, unnecessary, or insecure code.
> 
> Just recently I removed a couple algorithms (keywrap and vmac).  Looking
> back in more detail, there was actually never any use case presented for
> their inclusion, and they were never used.  So all the effort spent
> reviewing and maintaining that code was just wasted.  We could have just
> never added them in the first place and saved tons of time.

Looking at both lib/crypto/ and crypto/ directories, I initially did not
have an impression that mandatory in-kernel use of a cryptographic hash
function is a strict requirement for its inclusion in the linux kernel.
Such requirement is also not mentioned in the section "Adding New Algorithms"
of https://docs.kernel.org/crypto/api-intro.html. Now that you give a
historical context of it, so I completely understand your point.

> So this is nothing about Ascon not being a good algorithm, but rather
> we're just careful about adding unused code, as we don't want to repeat
> past mistakes.  And as you've made clear, currently you'd like to add
> the algorithm just for its own sake and there is no planned user --
> which is concerning.  I'm not sure if this is a school project or what
> not, but we don't really do that, sorry.  There has to be a clear
> technical justification with an in-kernel use case.

I am an external contractor working for a client that asked an implementation
of Ascon family of algorithms in the linux kernel, but did not disclose
its use case.

Just a heads up: I will send v2 of this patch to fix a compilation error
and a build warning. I will also send a separate patch that implements
Ascon-XOF128 and Ascon-CXOF128. I hope you understand that I simply have to
finish the tasks assigned to me, and these are not meant as an attempt to
put pressure for their acceptance.

On the other hand, I am also keen to see its possible use cases in the linux
kernel. Ascon-Hash256 specifically can be an alternative to SHA-256. For
instance, it can be an additional option of hash function in fs-verity for
processors with no SHA256 dedicated instructions. If that something that
interests you, I am open for further discussion.

> - Eric
>

Best,
Rusydi

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 0/3] Implementation of Ascon-Hash256
  2025-12-31  9:20           ` Rusydi H. Makarim
@ 2026-01-01 21:06             ` Eric Biggers
  2026-01-01 23:35               ` David Laight
  0 siblings, 1 reply; 17+ messages in thread
From: Eric Biggers @ 2026-01-01 21:06 UTC (permalink / raw)
  To: Rusydi H. Makarim
  Cc: Herbert Xu, David S. Miller, Jason A. Donenfeld, Ard Biesheuvel,
	linux-kernel, linux-crypto

On Wed, Dec 31, 2025 at 04:20:40PM +0700, Rusydi H. Makarim wrote:
> On Tue, Dec 16, 2025 at 08:06:17PM -0800, Eric Biggers wrote:
> > On Wed, Dec 17, 2025 at 10:33:22AM +0700, Rusydi H. Makarim wrote:
> > > On 2025-12-17 01:02, Eric Biggers wrote:
> > > > On Tue, Dec 16, 2025 at 01:27:17PM +0700, Rusydi H. Makarim wrote:
> > > > > While no direct in-kernel use as of now
> > > > 
> > > > Thanks for confirming.  We only add algorithms when there is a real
> > > > user, so it's best to hold off on this for now.
> > > > 
> > > > - Eric
> > > 
> > > Rather than leaving this work idle, would it be better to move the
> > > implementation entirely into the Crypto API ?
> > 
> > No, that's actually the most problematic part because it would put it in
> > the name-based registry and become impossible to change later.
> > 
> > There's a large maintenance cost to supporting algorithms.  We've
> > learned this the hard way.  In the past the requirements to add new
> > algorithms to the kernel were much more relaxed, and as a result, the
> > Linux kernel community has ended up wasting lots of time maintaining
> > unused, unnecessary, or insecure code.
> > 
> > Just recently I removed a couple algorithms (keywrap and vmac).  Looking
> > back in more detail, there was actually never any use case presented for
> > their inclusion, and they were never used.  So all the effort spent
> > reviewing and maintaining that code was just wasted.  We could have just
> > never added them in the first place and saved tons of time.
> 
> Looking at both lib/crypto/ and crypto/ directories, I initially did not
> have an impression that mandatory in-kernel use of a cryptographic hash
> function is a strict requirement for its inclusion in the linux kernel.

It's no different from any other Linux kernel feature.

> On the other hand, I am also keen to see its possible use cases in the linux
> kernel. Ascon-Hash256 specifically can be an alternative to SHA-256. For
> instance, it can be an additional option of hash function in fs-verity for
> processors with no SHA256 dedicated instructions. If that something that
> interests you, I am open for further discussion.

I haven't actually seen any demand for alternative hash functions in
fs-verity.  Though, dm-verity is sometimes used with BLAKE2b for the
reason you mention.  But this also means the kernel crypto subsystem
already has alternatives to SHA-256.  With that being the case, it's not
clear that adding another one would bring anything new to the table.
How does the performance compare with BLAKE2s and BLAKE2b?

- Eric

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 0/3] Implementation of Ascon-Hash256
  2026-01-01 21:06             ` Eric Biggers
@ 2026-01-01 23:35               ` David Laight
  0 siblings, 0 replies; 17+ messages in thread
From: David Laight @ 2026-01-01 23:35 UTC (permalink / raw)
  To: Eric Biggers
  Cc: Rusydi H. Makarim, Herbert Xu, David S. Miller,
	Jason A. Donenfeld, Ard Biesheuvel, linux-kernel, linux-crypto

On Thu, 1 Jan 2026 13:06:02 -0800
Eric Biggers <ebiggers@kernel.org> wrote:

> On Wed, Dec 31, 2025 at 04:20:40PM +0700, Rusydi H. Makarim wrote:
> > On Tue, Dec 16, 2025 at 08:06:17PM -0800, Eric Biggers wrote:  
> > > On Wed, Dec 17, 2025 at 10:33:22AM +0700, Rusydi H. Makarim wrote:  
> > > > On 2025-12-17 01:02, Eric Biggers wrote:  
> > > > > On Tue, Dec 16, 2025 at 01:27:17PM +0700, Rusydi H. Makarim wrote:  
> > > > > > While no direct in-kernel use as of now  
> > > > > 
> > > > > Thanks for confirming.  We only add algorithms when there is a real
> > > > > user, so it's best to hold off on this for now.
> > > > > 
> > > > > - Eric  
> > > > 
> > > > Rather than leaving this work idle, would it be better to move the
> > > > implementation entirely into the Crypto API ?  
> > > 
> > > No, that's actually the most problematic part because it would put it in
> > > the name-based registry and become impossible to change later.
> > > 
> > > There's a large maintenance cost to supporting algorithms.  We've
> > > learned this the hard way.  In the past the requirements to add new
> > > algorithms to the kernel were much more relaxed, and as a result, the
> > > Linux kernel community has ended up wasting lots of time maintaining
> > > unused, unnecessary, or insecure code.
> > > 
> > > Just recently I removed a couple algorithms (keywrap and vmac).  Looking
> > > back in more detail, there was actually never any use case presented for
> > > their inclusion, and they were never used.  So all the effort spent
> > > reviewing and maintaining that code was just wasted.  We could have just
> > > never added them in the first place and saved tons of time.  
> > 
> > Looking at both lib/crypto/ and crypto/ directories, I initially did not
> > have an impression that mandatory in-kernel use of a cryptographic hash
> > function is a strict requirement for its inclusion in the linux kernel.  
> 
> It's no different from any other Linux kernel feature.
> 
> > On the other hand, I am also keen to see its possible use cases in the linux
> > kernel. Ascon-Hash256 specifically can be an alternative to SHA-256. For
> > instance, it can be an additional option of hash function in fs-verity for
> > processors with no SHA256 dedicated instructions. If that something that
> > interests you, I am open for further discussion.  
> 
> I haven't actually seen any demand for alternative hash functions in
> fs-verity.  Though, dm-verity is sometimes used with BLAKE2b for the
> reason you mention.  But this also means the kernel crypto subsystem
> already has alternatives to SHA-256.  With that being the case, it's not
> clear that adding another one would bring anything new to the table.
> How does the performance compare with BLAKE2s and BLAKE2b?

FYI blake2b (64bit) runs at a little under 3 clocks/byte fully unrolled
on my Zen5 cpu (I've not tried in Intel cpu yet, and need a newer one).
With the main loop not unrolled it is about 4 clocks/byte.
(I've not yet tried to see why it makes that much difference.)
But the 'elephant in the room' is the 'cold cache' case.
The break-even point is somewhere between 4k and 8k bytes
(and that is excluding the effect of evicting other code from the I-cache).

Blake2s (32bit) will run at half the speed - provided the cpu has
enough registers.
Blake2s and blake2b really need a few more than 16 registers - which 32bit
x86 doesn't have.

So something with a much smaller I-cache footprint might be useful.

	David


> 
> - Eric
> 


^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2026-01-01 23:35 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-12-15  7:54 [PATCH 0/3] Implementation of Ascon-Hash256 Rusydi H. Makarim
2025-12-15  7:54 ` [PATCH 1/3] lib/crypto: Add KUnit test vectors for Ascon-Hash256 Rusydi H. Makarim
2025-12-19  4:29   ` kernel test robot
2025-12-22 17:11   ` kernel test robot
2025-12-15  7:54 ` [PATCH 2/3] lib/crypto: Initial implementation of Ascon-Hash256 Rusydi H. Makarim
2025-12-15 23:01   ` kernel test robot
2025-12-20 15:34   ` kernel test robot
2025-12-20 16:20   ` kernel test robot
2025-12-22 17:41   ` kernel test robot
2025-12-15  7:54 ` [PATCH 3/3] crypto: Crypto API " Rusydi H. Makarim
2025-12-15 20:19 ` [PATCH 0/3] Implementation " Eric Biggers
2025-12-16  6:27   ` Rusydi H. Makarim
2025-12-16 18:02     ` Eric Biggers
     [not found]       ` <bb05699bc7922bb3668082367b4750f2@kriptograf.id>
2025-12-17  4:06         ` Eric Biggers
2025-12-31  9:20           ` Rusydi H. Makarim
2026-01-01 21:06             ` Eric Biggers
2026-01-01 23:35               ` David Laight

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).