* [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
* 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 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
* [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
* 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 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 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
* [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 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
[parent not found: <bb05699bc7922bb3668082367b4750f2@kriptograf.id>]
* 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 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).