- nettle-bugs - lists.lysator.liu.se

Trimming sha3 context struct
by Niels Möller 13 May '25

13 May '25

Hi, I recently realized that unlike other hash functions in Nettle, we can do without the block size buffer for sha3. Below patch reduces the buffer to just 8 bytes, since input can be xored directly to the state array (with the extra 8-byte buffer used for partial words on big endian platforms), and similarly, shake output can ge generated from the state array. The implementation of _update and _shake_output becomes a bit more complex, with separate code for big and little endian platforms. I had expected a minor speedup for little-endian, but I haven't seen any significant performance changes on my x86_64 machine. Before, the size of the context structs ranged from 280 bytes for sha3_512 to 352 bytes for sha3_224 and 376 for shake128. After these changes, all variants use the same context struct of 216 bytes. One can then eliminate the different struct sha3_*_ctx, replacing with a single struct sha3_ctx, and similarly only a single sha3_init function. Would it be useful to keep old names as preprocessor aliases? Either by default, or via a separate header nettle/sha3-compat.h? Regards, /Niels --------------8<--------- diff --git a/ed448-shake256-pubkey.c b/ed448-shake256-pubkey.c index bde18278..ce031aac 100644 --- a/ed448-shake256-pubkey.c +++ b/ed448-shake256-pubkey.c @@ -44,14 +44,14 @@ void ed448_shake256_public_key (uint8_t *pub, const uint8_t *priv) { const struct ecc_curve *ecc = &_nettle_curve448; - struct sha3_256_ctx ctx; + struct sha3_ctx ctx; uint8_t digest[ED448_SIGNATURE_SIZE]; mp_size_t itch = ecc->q.size + _eddsa_public_key_itch (ecc); mp_limb_t *scratch = gmp_alloc_limbs (itch); #define k scratch #define scratch_out (scratch + ecc->q.size) - sha3_256_init (&ctx); + sha3_init (&ctx); _eddsa_expand_key (ecc, &_nettle_ed448_shake256, &ctx, priv, digest, k); _eddsa_public_key (ecc, k, pub, scratch_out); diff --git a/ed448-shake256-sign.c b/ed448-shake256-sign.c index c524593d..5d3cdbd5 100644 --- a/ed448-shake256-sign.c +++ b/ed448-shake256-sign.c @@ -52,10 +52,10 @@ ed448_shake256_sign (const uint8_t *pub, mp_limb_t *scratch = gmp_alloc_limbs (itch); #define k2 scratch #define scratch_out (scratch + ecc->q.size) - struct sha3_256_ctx ctx; + struct sha3_ctx ctx; uint8_t digest[ED448_SIGNATURE_SIZE]; - sha3_256_init (&ctx); + sha3_init (&ctx); _eddsa_expand_key (ecc, eddsa, &ctx, priv, digest, k2); _eddsa_sign (ecc, eddsa, &ctx, diff --git a/ed448-shake256-verify.c b/ed448-shake256-verify.c index af16f107..0134faae 100644 --- a/ed448-shake256-verify.c +++ b/ed448-shake256-verify.c @@ -50,11 +50,11 @@ ed448_shake256_verify (const uint8_t *pub, const struct ecc_curve *ecc = &_nettle_curve448; mp_size_t itch = 3*ecc->p.size + _eddsa_verify_itch (ecc); mp_limb_t *scratch = gmp_alloc_limbs (itch); - struct sha3_256_ctx ctx; + struct sha3_ctx ctx; int res; #define A scratch #define scratch_out (scratch + 3*ecc->p.size) - sha3_256_init (&ctx); + sha3_init (&ctx); res = (_eddsa_decompress (ecc, A, pub, scratch_out) diff --git a/ed448-shake256.c b/ed448-shake256.c index 4522a158..b00150d4 100644 --- a/ed448-shake256.c +++ b/ed448-shake256.c @@ -52,7 +52,7 @@ ed448_dom(void *ctx) } static void -ed448_digest(struct sha3_256_ctx *ctx, uint8_t *digest) +ed448_digest(struct sha3_ctx *ctx, uint8_t *digest) { sha3_256_shake(ctx, 2*ED448_KEY_SIZE, digest); } diff --git a/nettle-internal.h b/nettle-internal.h index 81d06e80..1aed1007 100644 --- a/nettle-internal.h +++ b/nettle-internal.h @@ -39,7 +39,7 @@ #include <stdlib.h> /* For definition of NETTLE_MAX_HASH_CONTEXT_SIZE. */ -#include "sha3.h" +#include "streebog.h" /* Temporary allocation, for systems that don't support alloca. Note * that the allocation requests should always be reasonably small, so @@ -74,7 +74,7 @@ /* Limits that apply to systems that don't have alloca */ #define NETTLE_MAX_HASH_BLOCK_SIZE 144 /* For sha3_224*/ #define NETTLE_MAX_HASH_DIGEST_SIZE 64 -#define NETTLE_MAX_HASH_CONTEXT_SIZE (sizeof(struct sha3_224_ctx)) +#define NETTLE_MAX_HASH_CONTEXT_SIZE (sizeof(struct streebog512_ctx)) #define NETTLE_MAX_SEXP_ASSOC 17 #define NETTLE_MAX_CIPHER_BLOCK_SIZE 32 #define NETTLE_MAX_CIPHER_KEY_SIZE 32 diff --git a/sha3-224-meta.c b/sha3-224-meta.c index bf39bc3b..6c5a76cd 100644 --- a/sha3-224-meta.c +++ b/sha3-224-meta.c @@ -39,4 +39,4 @@ #include "sha3-internal.h" const struct nettle_hash nettle_sha3_224 -= _NETTLE_HASH(sha3_224, SHA3_224); += _NETTLE_SHA3_HASH(sha3_224, SHA3_224); diff --git a/sha3-224.c b/sha3-224.c index 08afce69..0b20d19b 100644 --- a/sha3-224.c +++ b/sha3-224.c @@ -35,32 +35,17 @@ # include "config.h" #endif -#include <stddef.h> -#include <string.h> - #include "sha3.h" #include "sha3-internal.h" -#include "nettle-write.h" - -void -sha3_224_init (struct sha3_224_ctx *ctx) -{ - memset (ctx, 0, offsetof (struct sha3_224_ctx, block)); -} - void -sha3_224_update (struct sha3_224_ctx *ctx, size_t length, const uint8_t *data) +sha3_224_update (struct sha3_ctx *ctx, size_t length, const uint8_t *data) { - ctx->index = _nettle_sha3_update (&ctx->state, - SHA3_224_BLOCK_SIZE, ctx->block, - ctx->index, length, data); + _nettle_sha3_update (ctx, SHA3_224_BLOCK_SIZE >> 3, length, data); } void -sha3_224_digest(struct sha3_224_ctx *ctx, uint8_t *digest) +sha3_224_digest(struct sha3_ctx *ctx, uint8_t *digest) { - _sha3_pad_hash (&ctx->state, SHA3_224_BLOCK_SIZE, ctx->block, ctx->index); - _nettle_write_le64 (SHA3_224_DIGEST_SIZE, digest, ctx->state.a); - sha3_224_init (ctx); + _nettle_sha3_digest (ctx, SHA3_224_BLOCK_SIZE >> 3, SHA3_224_DIGEST_SIZE, digest); } diff --git a/sha3-256-meta.c b/sha3-256-meta.c index 649d7422..40e841e7 100644 --- a/sha3-256-meta.c +++ b/sha3-256-meta.c @@ -39,4 +39,4 @@ #include "sha3-internal.h" const struct nettle_hash nettle_sha3_256 -= _NETTLE_HASH(sha3_256, SHA3_256); += _NETTLE_SHA3_HASH(sha3_256, SHA3_256); diff --git a/sha3-256.c b/sha3-256.c index c347e13b..557c69f3 100644 --- a/sha3-256.c +++ b/sha3-256.c @@ -35,32 +35,17 @@ # include "config.h" #endif -#include <stddef.h> -#include <string.h> - #include "sha3.h" #include "sha3-internal.h" -#include "nettle-write.h" - -void -sha3_256_init (struct sha3_256_ctx *ctx) -{ - memset (ctx, 0, offsetof (struct sha3_256_ctx, block)); -} - void -sha3_256_update (struct sha3_256_ctx *ctx, size_t length, const uint8_t *data) +sha3_256_update (struct sha3_ctx *ctx, size_t length, const uint8_t *data) { - ctx->index = _nettle_sha3_update (&ctx->state, - SHA3_256_BLOCK_SIZE, ctx->block, - ctx->index, length, data); + _nettle_sha3_update (ctx, SHA3_256_BLOCK_SIZE >> 3, length, data); } void -sha3_256_digest(struct sha3_256_ctx *ctx, uint8_t *digest) +sha3_256_digest(struct sha3_ctx *ctx, uint8_t *digest) { - _sha3_pad_hash (&ctx->state, SHA3_256_BLOCK_SIZE, ctx->block, ctx->index); - _nettle_write_le64 (SHA3_256_DIGEST_SIZE, digest, ctx->state.a); - sha3_256_init (ctx); + _nettle_sha3_digest (ctx, SHA3_256_BLOCK_SIZE >> 3, SHA3_256_DIGEST_SIZE, digest); } diff --git a/sha3-384-meta.c b/sha3-384-meta.c index 38373394..2c03d711 100644 --- a/sha3-384-meta.c +++ b/sha3-384-meta.c @@ -39,4 +39,4 @@ #include "sha3-internal.h" const struct nettle_hash nettle_sha3_384 -= _NETTLE_HASH(sha3_384, SHA3_384); += _NETTLE_SHA3_HASH(sha3_384, SHA3_384); diff --git a/sha3-384.c b/sha3-384.c index ea8dd038..13a4ef29 100644 --- a/sha3-384.c +++ b/sha3-384.c @@ -35,32 +35,17 @@ # include "config.h" #endif -#include <stddef.h> -#include <string.h> - #include "sha3.h" #include "sha3-internal.h" -#include "nettle-write.h" - -void -sha3_384_init (struct sha3_384_ctx *ctx) -{ - memset (ctx, 0, offsetof (struct sha3_384_ctx, block)); -} - void -sha3_384_update (struct sha3_384_ctx *ctx, size_t length, const uint8_t *data) +sha3_384_update (struct sha3_ctx *ctx, size_t length, const uint8_t *data) { - ctx->index = _nettle_sha3_update (&ctx->state, - SHA3_384_BLOCK_SIZE, ctx->block, - ctx->index, length, data); + _nettle_sha3_update (ctx, SHA3_384_BLOCK_SIZE >> 3, length, data); } void -sha3_384_digest(struct sha3_384_ctx *ctx, uint8_t *digest) +sha3_384_digest(struct sha3_ctx *ctx, uint8_t *digest) { - _sha3_pad_hash (&ctx->state, SHA3_384_BLOCK_SIZE, ctx->block, ctx->index); - _nettle_write_le64 (SHA3_384_DIGEST_SIZE, digest, ctx->state.a); - sha3_384_init (ctx); + _nettle_sha3_digest (ctx, SHA3_384_BLOCK_SIZE >> 3, SHA3_384_DIGEST_SIZE, digest); } diff --git a/sha3-512-meta.c b/sha3-512-meta.c index aff96373..61c22220 100644 --- a/sha3-512-meta.c +++ b/sha3-512-meta.c @@ -39,4 +39,4 @@ #include "sha3-internal.h" const struct nettle_hash nettle_sha3_512 -= _NETTLE_HASH(sha3_512, SHA3_512); += _NETTLE_SHA3_HASH(sha3_512, SHA3_512); diff --git a/sha3-512.c b/sha3-512.c index 9ae014dc..632c50c0 100644 --- a/sha3-512.c +++ b/sha3-512.c @@ -35,32 +35,17 @@ # include "config.h" #endif -#include <stddef.h> -#include <string.h> - #include "sha3.h" #include "sha3-internal.h" -#include "nettle-write.h" - -void -sha3_512_init (struct sha3_512_ctx *ctx) -{ - memset (ctx, 0, offsetof (struct sha3_512_ctx, block)); -} - void -sha3_512_update (struct sha3_512_ctx *ctx, size_t length, const uint8_t *data) +sha3_512_update (struct sha3_ctx *ctx, size_t length, const uint8_t *data) { - ctx->index = _nettle_sha3_update (&ctx->state, - SHA3_512_BLOCK_SIZE, ctx->block, - ctx->index, length, data); + _nettle_sha3_update (ctx, SHA3_512_BLOCK_SIZE >> 3, length, data); } void -sha3_512_digest(struct sha3_512_ctx *ctx, uint8_t *digest) +sha3_512_digest(struct sha3_ctx *ctx, uint8_t *digest) { - _sha3_pad_hash (&ctx->state, SHA3_512_BLOCK_SIZE, ctx->block, ctx->index); - _nettle_write_le64 (SHA3_512_DIGEST_SIZE, digest, ctx->state.a); - sha3_512_init (ctx); + _nettle_sha3_digest (ctx, SHA3_512_BLOCK_SIZE >> 3, SHA3_512_DIGEST_SIZE, digest); } diff --git a/sha3-internal.h b/sha3-internal.h index 669b9449..8a09db45 100644 --- a/sha3-internal.h +++ b/sha3-internal.h @@ -39,35 +39,37 @@ #define SHA3_HASH_MAGIC 6 #define SHA3_SHAKE_MAGIC 0x1f -unsigned -_nettle_sha3_update (struct sha3_state *state, - unsigned block_size, uint8_t *block, - unsigned pos, - size_t length, const uint8_t *data); - +void +_nettle_sha3_init (struct sha3_ctx *ctx); +/* For all functions, the block_size is in units of uint64_t words. */ void -_nettle_sha3_pad (struct sha3_state *state, - unsigned block_size, uint8_t *block, unsigned pos, uint8_t magic); +_nettle_sha3_update (struct sha3_ctx *ctx, unsigned block_size, + size_t length, const uint8_t *data); -#define _sha3_pad_hash(state, block_size, block, pos) do { \ - _nettle_sha3_pad (state, block_size, block, pos, SHA3_HASH_MAGIC); \ - sha3_permute (state); \ - } while (0) +void +_nettle_sha3_pad (struct sha3_ctx *ctx, unsigned block_size, uint8_t magic); -#define _sha3_pad_shake(state, block_size, block, pos) \ - _nettle_sha3_pad (state, block_size, block, pos, SHA3_SHAKE_MAGIC) +void +_nettle_sha3_digest (struct sha3_ctx *ctx, unsigned block_size, + unsigned digest_size, uint8_t *digest); void -_nettle_sha3_shake (struct sha3_state *state, - unsigned block_size, uint8_t *block, - unsigned index, +_nettle_sha3_shake (struct sha3_ctx *ctx, unsigned block_size, size_t length, uint8_t *dst); -unsigned -_nettle_sha3_shake_output (struct sha3_state *state, - unsigned block_size, uint8_t *block, - unsigned index, +void +_nettle_sha3_shake_output (struct sha3_ctx *ctx, unsigned block_size, size_t length, uint8_t *dst); +#define _NETTLE_SHA3_HASH(name, NAME) { \ + #name, \ + sizeof(struct sha3_ctx), \ + NAME##_DIGEST_SIZE, \ + NAME##_BLOCK_SIZE, \ + (nettle_hash_init_func *) sha3_init, \ + (nettle_hash_update_func *) name##_update, \ + (nettle_hash_digest_func *) name##_digest \ +} + #endif diff --git a/sha3-shake.c b/sha3-shake.c index d9312bbb..3e0ab634 100644 --- a/sha3-shake.c +++ b/sha3-shake.c @@ -41,76 +41,109 @@ #include "sha3.h" #include "sha3-internal.h" +#include "bswap-internal.h" +#include "macros.h" #include "nettle-write.h" void -_nettle_sha3_shake (struct sha3_state *state, - unsigned block_size, uint8_t *block, - unsigned index, +_nettle_sha3_shake (struct sha3_ctx *ctx, unsigned block_size, size_t length, uint8_t *dst) { - _sha3_pad_shake (state, block_size, block, index); + _nettle_sha3_pad (ctx, block_size, SHA3_SHAKE_MAGIC); + + /* Use byte units. */ + block_size <<= 3; while (length > block_size) { - sha3_permute (state); - _nettle_write_le64 (block_size, dst, state->a); - length -= block_size; - dst += block_size; + sha3_permute (&ctx->state); + _nettle_write_le64 (block_size, dst, ctx->state.a); + length -= block_size; dst += block_size; } - sha3_permute (state); - _nettle_write_le64 (length, dst, state->a); + sha3_permute (&ctx->state); + _nettle_write_le64 (length, dst, ctx->state.a); + sha3_init (ctx); } -unsigned -_nettle_sha3_shake_output (struct sha3_state *state, - unsigned block_size, uint8_t *block, - unsigned index, +void +_nettle_sha3_shake_output (struct sha3_ctx *ctx, unsigned block_size, size_t length, uint8_t *dst) { - unsigned left; + unsigned index = ctx->index; + unsigned block_bytes = block_size << 3; - /* We use one's complement of the index value to indicate SHAKE is - initialized. */ - if (index < block_size) + if (!ctx->shake_flag) { /* This is the first call of _shake_output. */ - _sha3_pad_shake (state, block_size, block, index); + _nettle_sha3_pad (ctx, block_size, SHA3_SHAKE_MAGIC); /* Point at the end of block to trigger fill in of the buffer. */ - index = block_size; + index = block_bytes; + ctx->shake_flag = 1; } - else - index = ~index; - assert (index <= block_size); + assert (index <= block_bytes); + { +#if WORDS_BIGENDIAN + unsigned byte_index = index & 7; - /* Write remaining data from the buffer. */ - left = block_size - index; + if (byte_index) + { + unsigned left = 8 - byte_index; if (length <= left) { - memcpy (dst, block + index, length); - return ~(index + length); + memcpy (dst, ctx->block.b + byte_index, length); + ctx->index = index + length; + return; + } + memcpy (dst, ctx->block.b + byte_index, left); + dst += left; length -= left; index += left; + } + + /* Switch to units of words */ + index >>= 3; + + for (; length > 0; length -= 8, dst += 8, index++) + { + if (index == block_size) + { + sha3_permute (&ctx->state); + index = 0; + } + if (length < 8) + { + ctx->block.u64 = nettle_bswap64 (ctx->state.a[index]); + memcpy (dst, ctx->block.b, length); + break; + } + LE_WRITE_UINT64(dst, ctx->state.a[index]); + } + ctx->index = (index << 3) + length; +#else /* !WORDS_BIGENDIAN */ + size_t left = block_bytes - index; + if (length <= left) + { + memcpy (dst, ((const uint8_t *) ctx->state.a) + index, length); + ctx->index = index + length; + return; } else { - memcpy (dst, block + index, left); + memcpy (dst, ((const uint8_t *) ctx->state.a) + index, left); length -= left; dst += left; } /* Write full blocks. */ - while (length > block_size) + for (; length > block_bytes; length -= block_bytes, dst += block_bytes) { - sha3_permute (state); - _nettle_write_le64 (block_size, dst, state->a); - length -= block_size; - dst += block_size; + sha3_permute (&ctx->state); + _nettle_write_le64 (block_bytes, dst, ctx->state.a); } - sha3_permute (state); - /* Fill in the buffer for next call. */ - _nettle_write_le64 (block_size, block, state->a); - memcpy (dst, block, length); - return ~length; + sha3_permute (&ctx->state); + memcpy (dst, ctx->state.a, length); + ctx->index = length; +#endif /* !WORDS_BIGENDIAN */ + } } diff --git a/sha3.c b/sha3.c index d2f27323..f378b9c6 100644 --- a/sha3.c +++ b/sha3.c @@ -35,70 +35,110 @@ # include "config.h" #endif -#include <assert.h> #include <string.h> #include "sha3.h" #include "sha3-internal.h" +#include "bswap-internal.h" #include "macros.h" -#include "md-internal.h" #include "memxor.h" +#include "nettle-write.h" -#if WORDS_BIGENDIAN -static void -sha3_xor_block (struct sha3_state *state, unsigned length, const uint8_t *data) -{ - assert ( (length & 7) == 0); - { - uint64_t *p; - for (p = state->a; length > 0; p++, length -= 8, data += 8) - *p ^= LE_READ_UINT64 (data); - } -} -#else /* !WORDS_BIGENDIAN */ -#define sha3_xor_block(state, length, data) memxor (state->a, data, length) -#endif - -static void -sha3_absorb (struct sha3_state *state, unsigned length, const uint8_t *data) +void +sha3_init (struct sha3_ctx *ctx) { - sha3_xor_block (state, length, data); - sha3_permute (state); + memset (ctx, 0, offsetof (struct sha3_ctx, block)); } -unsigned -_nettle_sha3_update (struct sha3_state *state, - unsigned block_size, uint8_t *block, - unsigned pos, +void +_nettle_sha3_update (struct sha3_ctx *ctx, unsigned block_size, size_t length, const uint8_t *data) { - assert (pos < block_size); +#if WORDS_BIGENDIAN + unsigned byte_index = ctx->index & 7; + unsigned index = ctx->index >> 3; - if (!length) - return pos; + if (byte_index > 0) + { + unsigned left = sizeof (ctx->block) - byte_index; + if (length < left) + { + memcpy (ctx->block.b + byte_index, data, length); + ctx->index += length; + return; + } + memcpy (ctx->block.b + byte_index, data, left); + data += left; length -= left; - if (pos > 0) + ctx->state.a[index++] ^= nettle_bswap64 (ctx->block.u64); + if (index == block_size) { - MD_FILL_OR_RETURN_INDEX (block_size, block, pos, length, data); - sha3_absorb (state, block_size, block); + sha3_permute (&ctx->state); + index = 0; + } } - for (; length >= block_size; length -= block_size, data += block_size) - sha3_absorb (state, block_size, data); - memcpy (block, data, length); - return length; + for (; length >= 8; length -= 8, data += 8) + { + ctx->state.a[index++] ^= LE_READ_UINT64 (data); + if (index == block_size) + { + sha3_permute (&ctx->state); + index = 0; + } + } + memcpy (ctx->block.b, data, length); + ctx->index = (index << 3) + length; +#else /* !WORDS_BIGENDIAN */ + /* Switch to units of bytes. */ + block_size <<= 3; + if (ctx->index > 0) + { + unsigned left = block_size - ctx->index; + if (length < left) + { + memxor ((uint8_t *) ctx->state.a + ctx->index, data, length); + ctx->index += length; + return; + } + memxor ((uint8_t *) ctx->state.a + ctx->index, data, left); + data += left; length -= left; + ctx->index = 0; + sha3_permute (&ctx->state); + } + for (; length >= block_size; length -= block_size, data += block_size) + { + memxor ((uint8_t *) ctx->state.a, data, block_size); + sha3_permute (&ctx->state); + } + memxor ((uint8_t *) ctx->state.a, data, length); + ctx->index = length; +#endif /* !WORDS_BIGENDIAN */ } void -_nettle_sha3_pad (struct sha3_state *state, - unsigned block_size, uint8_t *block, unsigned pos, uint8_t magic) +_nettle_sha3_pad (struct sha3_ctx *ctx, unsigned block_size, uint8_t magic) { - assert (pos < block_size); - block[pos++] = magic; +#if WORDS_BIGENDIAN + unsigned byte_index = ctx->index & 7; + unsigned word_index = ctx->index >> 3; - memset (block + pos, 0, block_size - pos); - block[block_size - 1] |= 0x80; + ctx->block.b[byte_index++] = magic; + memset (ctx->block.b + byte_index, 0, 8 - byte_index); + ctx->state.a[word_index] ^= nettle_bswap64 (ctx->block.u64); +#else /* !WORDS_BIGENDIAN */ + ((uint8_t *) ctx->state.a)[ctx->index] ^= magic; +#endif /* !WORDS_BIGENDIAN */ + ctx->state.a[block_size - 1] ^= (uint64_t) 1 << 63; +} - sha3_xor_block (state, block_size, block); +void +_nettle_sha3_digest (struct sha3_ctx *ctx, unsigned block_size, + unsigned digest_size, uint8_t *digest) +{ + _nettle_sha3_pad (ctx, block_size, SHA3_HASH_MAGIC); + sha3_permute (&ctx->state); + _nettle_write_le64 (digest_size, digest, ctx->state.a); + sha3_init (ctx); } diff --git a/sha3.h b/sha3.h index c499f395..7e4a7963 100644 --- a/sha3.h +++ b/sha3.h @@ -42,22 +42,18 @@ extern "C" { /* Name mangling */ #define sha3_permute nettle_sha3_permute -#define sha3_128_init nettle_sha3_128_init +#define sha3_init nettle_sha3_init #define sha3_128_update nettle_sha3_128_update #define sha3_128_shake nettle_sha3_128_shake #define sha3_128_shake_output nettle_sha3_128_shake_output -#define sha3_224_init nettle_sha3_224_init #define sha3_224_update nettle_sha3_224_update #define sha3_224_digest nettle_sha3_224_digest -#define sha3_256_init nettle_sha3_256_init #define sha3_256_update nettle_sha3_256_update #define sha3_256_digest nettle_sha3_256_digest #define sha3_256_shake nettle_sha3_256_shake #define sha3_256_shake_output nettle_sha3_256_shake_output -#define sha3_384_init nettle_sha3_384_init #define sha3_384_update nettle_sha3_384_update #define sha3_384_digest nettle_sha3_384_digest -#define sha3_512_init nettle_sha3_512_init #define sha3_512_update nettle_sha3_512_update #define sha3_512_digest nettle_sha3_512_digest @@ -98,98 +94,64 @@ sha3_permute (struct sha3_state *state); #define SHA3_512_DIGEST_SIZE 64 #define SHA3_512_BLOCK_SIZE 72 -struct sha3_128_ctx +struct sha3_ctx { struct sha3_state state; + /* The position in current block of next input byte (for update) or + next output byte (for shake). */ unsigned index; - uint8_t block[SHA3_128_BLOCK_SIZE]; + /* Set when shake output has been initialized. */ + int shake_flag; + /* Buffer for partial words; input and output from the state is + handled one uint64_t at a time. */ + union nettle_block8 block; }; void -sha3_128_init (struct sha3_128_ctx *ctx); +sha3_init (struct sha3_ctx *ctx); void -sha3_128_update (struct sha3_128_ctx *ctx, size_t length, const uint8_t *data); +sha3_128_update (struct sha3_ctx *ctx, size_t length, const uint8_t *data); void -sha3_128_shake (struct sha3_128_ctx *ctx, size_t length, uint8_t *digest); +sha3_128_shake (struct sha3_ctx *ctx, size_t length, uint8_t *digest); void -sha3_128_shake_output (struct sha3_128_ctx *ctx, size_t length, uint8_t *digest); - -struct sha3_224_ctx -{ - struct sha3_state state; - unsigned index; - uint8_t block[SHA3_224_BLOCK_SIZE]; -}; - -void -sha3_224_init (struct sha3_224_ctx *ctx); +sha3_128_shake_output (struct sha3_ctx *ctx, size_t length, uint8_t *digest); void -sha3_224_update (struct sha3_224_ctx *ctx, size_t length, const uint8_t *data); - -void -sha3_224_digest(struct sha3_224_ctx *ctx, uint8_t *digest); - -struct sha3_256_ctx -{ - struct sha3_state state; - unsigned index; - uint8_t block[SHA3_256_BLOCK_SIZE]; -}; +sha3_224_update (struct sha3_ctx *ctx, size_t length, const uint8_t *data); void -sha3_256_init (struct sha3_256_ctx *ctx); +sha3_224_digest(struct sha3_ctx *ctx, uint8_t *digest); void -sha3_256_update (struct sha3_256_ctx *ctx, size_t length, const uint8_t *data); +sha3_256_update (struct sha3_ctx *ctx, size_t length, const uint8_t *data); void -sha3_256_digest(struct sha3_256_ctx *ctx, uint8_t *digest); +sha3_256_digest(struct sha3_ctx *ctx, uint8_t *digest); /* Alternative digest function implementing shake256, with arbitrary digest size */ void -sha3_256_shake(struct sha3_256_ctx *ctx, size_t length, uint8_t *digest); +sha3_256_shake(struct sha3_ctx *ctx, size_t length, uint8_t *digest); /* Unlike sha3_256_shake, this function can be called multiple times to retrieve output from shake256 in an incremental manner */ void -sha3_256_shake_output(struct sha3_256_ctx *ctx, size_t length, uint8_t *digest); - -struct sha3_384_ctx -{ - struct sha3_state state; - unsigned index; - uint8_t block[SHA3_384_BLOCK_SIZE]; -}; - -void -sha3_384_init (struct sha3_384_ctx *ctx); +sha3_256_shake_output(struct sha3_ctx *ctx, size_t length, uint8_t *digest); void -sha3_384_update (struct sha3_384_ctx *ctx, size_t length, const uint8_t *data); - -void -sha3_384_digest(struct sha3_384_ctx *ctx, uint8_t *digest); - -struct sha3_512_ctx -{ - struct sha3_state state; - unsigned index; - uint8_t block[SHA3_512_BLOCK_SIZE]; -}; +sha3_384_update (struct sha3_ctx *ctx, size_t length, const uint8_t *data); void -sha3_512_init (struct sha3_512_ctx *ctx); +sha3_384_digest(struct sha3_ctx *ctx, uint8_t *digest); void -sha3_512_update (struct sha3_512_ctx *ctx, size_t length, const uint8_t *data); +sha3_512_update (struct sha3_ctx *ctx, size_t length, const uint8_t *data); void -sha3_512_digest(struct sha3_512_ctx *ctx, uint8_t *digest); +sha3_512_digest(struct sha3_ctx *ctx, uint8_t *digest); #ifdef __cplusplus } diff --git a/shake128.c b/shake128.c index f0c68e7d..5f8b9610 100644 --- a/shake128.c +++ b/shake128.c @@ -36,37 +36,23 @@ # include "config.h" #endif -#include <string.h> - #include "sha3.h" #include "sha3-internal.h" void -sha3_128_init (struct sha3_128_ctx *ctx) -{ - memset (ctx, 0, offsetof (struct sha3_128_ctx, block)); -} - -void -sha3_128_update (struct sha3_128_ctx *ctx, size_t length, const uint8_t *data) +sha3_128_update (struct sha3_ctx *ctx, size_t length, const uint8_t *data) { - ctx->index = _nettle_sha3_update (&ctx->state, - SHA3_128_BLOCK_SIZE, ctx->block, - ctx->index, length, data); + _nettle_sha3_update (ctx, SHA3_128_BLOCK_SIZE >> 3, length, data); } void -sha3_128_shake (struct sha3_128_ctx *ctx, size_t length, uint8_t *dst) +sha3_128_shake (struct sha3_ctx *ctx, size_t length, uint8_t *dst) { - _nettle_sha3_shake (&ctx->state, sizeof (ctx->block), ctx->block, ctx->index, length, dst); - sha3_128_init (ctx); + _nettle_sha3_shake (ctx, SHA3_128_BLOCK_SIZE >> 3, length, dst); } void -sha3_128_shake_output (struct sha3_128_ctx *ctx, size_t length, uint8_t *digest) +sha3_128_shake_output (struct sha3_ctx *ctx, size_t length, uint8_t *digest) { - ctx->index = - _nettle_sha3_shake_output (&ctx->state, - sizeof (ctx->block), ctx->block, ctx->index, - length, digest); + _nettle_sha3_shake_output (ctx, SHA3_128_BLOCK_SIZE >> 3, length, digest); } diff --git a/shake256.c b/shake256.c index de72cf96..05263b6e 100644 --- a/shake256.c +++ b/shake256.c @@ -40,17 +40,13 @@ #include "sha3-internal.h" void -sha3_256_shake (struct sha3_256_ctx *ctx, size_t length, uint8_t *dst) +sha3_256_shake (struct sha3_ctx *ctx, size_t length, uint8_t *dst) { - _nettle_sha3_shake (&ctx->state, sizeof (ctx->block), ctx->block, ctx->index, length, dst); - sha3_256_init (ctx); + _nettle_sha3_shake (ctx, SHA3_256_BLOCK_SIZE >> 3, length, dst); } void -sha3_256_shake_output (struct sha3_256_ctx *ctx, size_t length, uint8_t *digest) +sha3_256_shake_output (struct sha3_ctx *ctx, size_t length, uint8_t *digest) { - ctx->index = - _nettle_sha3_shake_output (&ctx->state, - sizeof (ctx->block), ctx->block, ctx->index, - length, digest); + _nettle_sha3_shake_output (ctx, SHA3_256_BLOCK_SIZE >> 3, length, digest); } diff --git a/testsuite/eddsa-sign-test.c b/testsuite/eddsa-sign-test.c index 2ea1e4bd..1bc80c94 100644 --- a/testsuite/eddsa-sign-test.c +++ b/testsuite/eddsa-sign-test.c @@ -119,9 +119,9 @@ test_ed448_sign (const struct tstring *public, const struct tstring *msg, const struct tstring *ref) { - struct sha3_256_ctx ctx; + struct sha3_ctx ctx; - sha3_256_init (&ctx); + sha3_init (&ctx); test_eddsa_sign (&_nettle_curve448, &_nettle_ed448_shake256, &ctx, public, private, msg, ref); } diff --git a/testsuite/eddsa-verify-test.c b/testsuite/eddsa-verify-test.c index cc853a55..de850626 100644 --- a/testsuite/eddsa-verify-test.c +++ b/testsuite/eddsa-verify-test.c @@ -142,9 +142,9 @@ test_ed448 (const uint8_t *pub, const struct tstring *msg, const uint8_t *signature) { - struct sha3_256_ctx ctx; + struct sha3_ctx ctx; - sha3_256_init (&ctx); + sha3_init (&ctx); test_eddsa (&_nettle_curve448, &_nettle_ed448_shake256, &ctx, pub, msg, signature); } diff --git a/testsuite/shake128-test.c b/testsuite/shake128-test.c index fd55b4b2..d1b71de9 100644 --- a/testsuite/shake128-test.c +++ b/testsuite/shake128-test.c @@ -37,9 +37,9 @@ const struct nettle_xof nettle_shake128 = { "shake128", - sizeof(struct sha3_128_ctx), + sizeof(struct sha3_ctx), SHA3_128_BLOCK_SIZE, - (nettle_hash_init_func *) sha3_128_init, + (nettle_hash_init_func *) sha3_init, (nettle_hash_update_func *) sha3_128_update, (nettle_output_func *) sha3_128_shake, (nettle_output_func *) sha3_128_shake_output, diff --git a/testsuite/shake256-test.c b/testsuite/shake256-test.c index 93e1107e..9f5d9ced 100644 --- a/testsuite/shake256-test.c +++ b/testsuite/shake256-test.c @@ -39,9 +39,9 @@ const struct nettle_xof nettle_shake256 = { "shake256", - sizeof(struct sha3_256_ctx), + sizeof(struct sha3_ctx), SHA3_256_BLOCK_SIZE, - (nettle_hash_init_func *) sha3_256_init, + (nettle_hash_init_func *) sha3_init, (nettle_hash_update_func *) sha3_256_update, (nettle_output_func *) sha3_256_shake, (nettle_output_func *) sha3_256_shake_output, -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

2 2

[PATCH] getopt: Fix getopt/getenv signatures in declarations
by Khem Raj 22 Mar '25

22 Mar '25

GCC-15 complains about this when trying to build on musl | ../nettle-3.10.1/getopt.c:139:14: error: conflicting types for 'getenv'; have 'char *(void)' | 139 | extern char *getenv (); | | ^~~~~~ --- getopt.c | 2 +- getopt.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/getopt.c b/getopt.c index 9d29de7..5b89302 100644 --- a/getopt.c +++ b/getopt.c @@ -136,7 +136,7 @@ static struct _getopt_data getopt_data; whose names are inconsistent. */ #ifndef getenv -extern char *getenv (); +extern char *getenv (const char *); #endif #endif /* not __GNU_LIBRARY__ */ diff --git a/getopt.h b/getopt.h index da1a01f..ab50792 100644 --- a/getopt.h +++ b/getopt.h @@ -166,7 +166,7 @@ extern int __posix_getopt (int ___argc, char *const *___argv, # endif # endif #else /* not __GNU_LIBRARY__ */ -extern int getopt (); +extern int getopt(int, char * const [], const char *); #endif /* __GNU_LIBRARY__ */ #ifndef __need_getopt

1 0

Incompatible changes
by Niels Möller 20 Mar '25

20 Mar '25

Hi, I've decided to start doing some of the cleanup changes that will break ABI and/or API (which has been stable since nettle-3.6, released 5 years ago). I think the more interesting planned changes are listed on https://git.lysator.liu.se/nettle/nettle/-/issues, and the most disruptive one is dropping the length argument for the various _digest functions (https://git.lysator.liu.se/nettle/nettle/-/issues/5). Changes will be released as nettle-4.0. Focus will be on changes affecting libnettle, to be able to get this done in a reasonable time, but it will nevertheless imply an soname bump also for libhogweed. If needed, bug fixes will be back-ported to a compatible nettle-3 branch, for additional 3.10.x releases. If you have opinions on what breaking changes should or shouldn't be done at this time, this is a good time to speak up. If that is helpful for applications to transition, I'm open to add some preprocessor defines or headers that can be used to get API (but not ABI) compatibility with nettle 3. Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

3 6

[PATCH] SLH-DSA
by Zoltan Fridrich 24 Feb '25

24 Feb '25

Hello, I would like to contribute an implementation of SLH-DSA to Nettle. The implementation is based off of the reference sphincs+ implementation and leancrypto slh-dsa implementation. Included tests contain test vectors from leancrypto slh-dsa tests. Could you please review the attached patch and give me your feedback? Kind regards, Zoltan

4 19

FOSDEM 2025
by Niels Möller 29 Jan '25

29 Jan '25

Hi, I just want to say that I'm going to FOSDEM this year. I will also do a talk in the security devroom on Saturday, https://fosdem.org/2025/schedule/event/fosdem-2025-5661-sigsum-detecting-ro… Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

1 0

ANNOUNCE: Nettle-3.10.1
by Niels Möller 30 Dec '24

30 Dec '24

I'm happy to announce a new release of GNU Nettle, a low-level cryptographics library. This release includes a few bug fixes and portability improvements. See NEWS entries below. Users of powerpc64 are adviced to upgrade; the bugs in the powerpc64 sha256 assembly of nettle-3.10 has the potential to cause crashes due to invalid memory read accesses. It's unclear if it could be exploitable, but it seems unlikely that any exploit could do worse than denial of service. The Nettle home page can be found at https://www.lysator.liu.se/~nisse/nettle/, and the manual at https://www.lysator.liu.se/~nisse/nettle/nettle.html. The release can be downloaded from https://ftp.gnu.org/gnu/nettle/nettle-3.10.1.tar.gz https://www.lysator.liu.se/~nisse/archive/nettle-3.10.1.tar.gz Happy hacking, /Niels Möller NEWS for the Nettle 3.10.1 release This is a maintenance release, with only a few bugfixes and portability improvements. The new version is intended to be fully source and binary compatible with Nettle-3.6. The shared library names are libnettle.so.8.10 and libhogweed.so.6.10, with sonames libnettle.so.8 and libhogweed.so.6. Bug fixes: * Fix buffer overread in the new sha256 assembly for powerpc64, as well as a stack alignment issue. * Added missing nettle_mac structs for hmac-gosthash. * Fix configure test for valgrind, to not attempt to run valgrind on executables built using memory sanitizers. Optimizations: * Improved runtime detection of cpu features for OpenBSD and FreeBSD, using elf_aux_info when available. This also adds runtime detection for FreeBSD on arm64. Contributed by Brad Smith. -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

1 0

[PATCH v2] powerpc64/sha256: fix loading overreads by loading less and shifting
by Eric Richter 13 Sep '24

13 Sep '24

Originally, the 16 input words were loaded with 16 individual vector load instructions. This has a side effect where the last three loads would overread 1/2/3 extra words. Fix the overread by replacing unnecessary overlapped reads with shifts. As a consequence, the constant registers for 4,8,12 can be removed, and also gain about 1~2% in performance. Signed-off-by: Eric Richter <erichte(a)linux.ibm.com> --- So this was supposed to be a simple update, removing those eight unnecessary instructions. However, removing the GPR store instructions introduced a performance regression of roughly -5% -- more performance lost than gained in the previous version. After a lot of trial-and-error, I've landed on this version, which includes yet another align, this time before the register storage section. I tried placing it in other locations, as well as changing the align value, eventually landing on this as the most performant version that I could find through brute force. Moving the load-immediate for TC16 to before the register save section marginally improved performance (<1%), and in a less technical opinion appears better than doing: ALIGN(16) li TC16, 16 ALIGN(16) lxv4wx lxv4wx When I have more time, I still intend to do a deeper dive and try to find out exactly why these aligns are helping/hurting performance. At minimum I'd like to send a patch for better comments to document the logic, so future implementations can learn from it. v2: - removed store/restore of now unused r14/r15 - moved the initial load of TC16 to be with other load immediates - changed .align to use the ALIGN macro - added an ALIGN before the register saving stores - added comments to ALIGN powerpc64/p8/sha256-compress-n.asm | 44 +++++++++++------------------- 1 file changed, 16 insertions(+), 28 deletions(-) diff --git a/powerpc64/p8/sha256-compress-n.asm b/powerpc64/p8/sha256-compress-n.asm index e08ae132..75666deb 100644 --- a/powerpc64/p8/sha256-compress-n.asm +++ b/powerpc64/p8/sha256-compress-n.asm @@ -44,10 +44,7 @@ define(`T1', `r8') define(`TK', `r9') define(`COUNT', `r10') define(`TC0', `0') C Index instructions allow literal 0 instead of a GPR -define(`TC4', `r11') -define(`TC8', `r12') -define(`TC12', `r14') -define(`TC16', `r15') +define(`TC16', `r11') C State registers define(`VSA', `v0') @@ -187,24 +184,24 @@ define(`LOAD', ` define(`DOLOADS', ` IF_LE(`DATA_LOAD_VEC(VT0, .load_swap, T1)') LOAD(0, TC0) - LOAD(1, TC4) - LOAD(2, TC8) - LOAD(3, TC12) + vsldoi IV(1), IV(0), IV(0), 4 + vsldoi IV(2), IV(0), IV(0), 8 + vsldoi IV(3), IV(0), IV(0), 12 addi INPUT, INPUT, 16 LOAD(4, TC0) - LOAD(5, TC4) - LOAD(6, TC8) - LOAD(7, TC12) + vsldoi IV(5), IV(4), IV(4), 4 + vsldoi IV(6), IV(4), IV(4), 8 + vsldoi IV(7), IV(4), IV(4), 12 addi INPUT, INPUT, 16 LOAD(8, TC0) - LOAD(9, TC4) - LOAD(10, TC8) - LOAD(11, TC12) + vsldoi IV(9), IV(8), IV(8), 4 + vsldoi IV(10), IV(8), IV(8), 8 + vsldoi IV(11), IV(8), IV(8), 12 addi INPUT, INPUT, 16 LOAD(12, TC0) - LOAD(13, TC4) - LOAD(14, TC8) - LOAD(15, TC12) + vsldoi IV(13), IV(12), IV(12), 4 + vsldoi IV(14), IV(12), IV(12), 8 + vsldoi IV(15), IV(12), IV(12), 12 addi INPUT, INPUT, 16 ') @@ -216,6 +213,8 @@ PROLOGUE(_nettle_sha256_compress_n) C Store non-volatile registers + ALIGN(16) C Appears necessary for optimal stores + li TC16, 16 li T0, -16 li T1, -32 stvx v20, T0, SP @@ -240,15 +239,8 @@ PROLOGUE(_nettle_sha256_compress_n) subi T1, T1, 32 stvx v30, T0, SP stvx v31, T1, SP - subi T0, T0, 32 - subi T1, T1, 32 - stdx r14, T0, SP - stdx r15, T1, SP - li TC4, 4 - li TC8, 8 - li TC12, 12 - li TC16, 16 + ALIGN(16) C Appears necessary for optimal loads C Load state values lxvw4x VSR(VSA), 0, STATE C VSA contains A,B,C,D @@ -345,10 +337,6 @@ PROLOGUE(_nettle_sha256_compress_n) subi T1, T1, 32 lvx v30, T0, SP lvx v31, T1, SP - subi T0, T0, 32 - subi T1, T1, 32 - ldx r14, T0, SP - ldx r15, T1, SP .done: mr r3, INPUT -- 2.46.0

2 2

[PATCH] Add support for elf_aux_info() on OpenBSD
by Brad Smith 09 Sep '24

09 Sep '24

Signed-off-by: Brad Smith <brad(a)comstyle.com> --- configure.ac | 2 +- fat-arm64.c | 11 ++++++++++- fat-ppc.c | 12 ++++++------ 3 files changed, 17 insertions(+), 8 deletions(-) diff --git a/configure.ac b/configure.ac index 4f27e663..1f53a890 100644 --- a/configure.ac +++ b/configure.ac @@ -212,7 +212,7 @@ LSH_FUNC_ALLOCA # getenv_secure is used for fat overrides, # getline is used in the testsuite -AC_CHECK_FUNCS(secure_getenv getline) +AC_CHECK_FUNCS(secure_getenv getline elf_aux_info) ASM_WORDS_BIGENDIAN=unknown AC_C_BIGENDIAN([AC_DEFINE([WORDS_BIGENDIAN], 1) diff --git a/fat-arm64.c b/fat-arm64.c index 45cce0cc..36136078 100644 --- a/fat-arm64.c +++ b/fat-arm64.c @@ -51,6 +51,8 @@ #if USE_GETAUXVAL # include <asm/hwcap.h> # include <sys/auxv.h> +#elif defined(HAVE_ELF_AUX_INFO) +# include <sys/auxv.h> #elif defined(__OpenBSD__) # include <sys/sysctl.h> # include <machine/cpu.h> @@ -133,8 +135,15 @@ get_arm64_features (struct arm64_features *features) } else { +#if USE_GETAUXVAL || defined(HAVE_ELF_AUX_INFO) + unsigned long hwcap = 0; + #if USE_GETAUXVAL - unsigned long hwcap = getauxval(AT_HWCAP); + hwcap = getauxval(AT_HWCAP); +#elif defined(HAVE_ELF_AUX_INFO) + elf_aux_info(AT_HWCAP, &hwcap, sizeof(hwcap)); +#endif + features->have_aes = ((hwcap & (HWCAP_ASIMD | HWCAP_AES)) == (HWCAP_ASIMD | HWCAP_AES)); features->have_pmull diff --git a/fat-ppc.c b/fat-ppc.c index aaccc116..c4dae3a1 100644 --- a/fat-ppc.c +++ b/fat-ppc.c @@ -48,14 +48,14 @@ # include <asm/cputable.h> # include <sys/auxv.h> # endif -#elif defined(__FreeBSD__) +#elif defined(__FreeBSD__) || defined(__OpenBSD__) # include <machine/cpu.h> # ifdef PPC_FEATURE2_HAS_VEC_CRYPTO # define PPC_FEATURE2_VEC_CRYPTO PPC_FEATURE2_HAS_VEC_CRYPTO # endif -# if __FreeBSD__ >= 12 +# ifdef HAVE_ELF_AUX_INFO # include <sys/auxv.h> -# else +# elif !defined(__OpenBSD__) # include <sys/sysctl.h> # endif #endif @@ -129,11 +129,11 @@ get_ppc_features (struct ppc_features *features) # if USE_GETAUXVAL hwcap = getauxval(AT_HWCAP); hwcap2 = getauxval(AT_HWCAP2); -# elif defined(__FreeBSD__) -# if __FreeBSD__ >= 12 +# elif defined(__FreeBSD__) || defined(__OpenBSD__) +# ifdef HAVE_ELF_AUX_INFO elf_aux_info(AT_HWCAP, &hwcap, sizeof(hwcap)); elf_aux_info(AT_HWCAP2, &hwcap2, sizeof(hwcap2)); -# else +# elif !defined(__OpenBSD__) size_t len; len = sizeof(hwcap); sysctlbyname("hw.cpu_features", &hwcap, &len, NULL, 0); -- 2.46.0

2 5

[PATCH] powerpc64/sha256: fix loading overreads by loading less and shifting
by Eric Richter 06 Sep '24

06 Sep '24

Originally, the 16 input words were loaded with 16 individual vector load instructions. This has a side effect where the last three loads would overread 1/2/3 extra words. Fix the overread by replacing unnecessary overlapped reads with shifts. As a consequence, the constant registers for 4,8,12 can be removed, and also gain about 1~2% in performance. Signed-off-by: Eric Richter <erichte(a)linux.ibm.com> --- Some additional comments, since I agree that the loads should be fixed, but a bit of a performance anomaly appeared: I thought I had tested this exact method in a previous iteration of the patches, and saw either no change or a minor performance hit. This time around I am seeing a slight performance improvement: (This is output from a script that compares 10-iteration benchmark runs, the values in parens are the difference from just changing the loads to shifts) alg/mode min avg max ====================== ============== ============== ============== sha256 update 460.64 (+2.45) 467.99 (+6.63) 468.89 (+7.13) hmac-sha256 64 bytes 126.39 (+0.94) 126.86 (+0.14) 127.42 (+0.08) hmac-sha256 256 bytes 272.14 (+2.97) 273.07 (+2.07) 273.60 (+1.44) hmac-sha256 1024 bytes 391.52 (+2.00) 393.17 (+2.03) 395.58 (+3.13) hmac-sha256 4096 bytes 440.61 (+3.22) 442.46 (+4.50) 444.15 (+5.73) hmac-sha256 single msg 454.75 (+1.23) 457.51 (+3.85) 459.70 (+5.91) However, removing the loads for the now unused TC registers now hurts performance by about the amount gained from using the shifts: Adding this change: - li TC4, 4 - li TC8, 8 - li TC12, 12 li TC16, 16 yields the following performance values (parens are difference against the code that did not remove the li's but did use shifts): alg/mode min avg max ====================== ============== ============== ============== sha256 update 462.47 (+1.83) 462.75 (-5.24) 462.87 (-6.02) hmac-sha256 64 bytes 126.01 (-0.38) 126.69 (-0.17) 127.00 (-0.42) hmac-sha256 256 bytes 270.13 (-2.01) 271.62 (-1.44) 272.99 (-0.61) hmac-sha256 1024 bytes 390.79 (-0.73) 391.84 (-1.33) 393.04 (-2.54) hmac-sha256 4096 bytes 438.60 (-2.01) 438.83 (-3.63) 439.30 (-4.85) hmac-sha256 single msg 454.52 (-0.23) 454.63 (-2.88) 454.76 (-4.94) If I add an align after the TC16 load: li TC16, 16 + .align 4 C Load state values lxvw4x VSR(VSA), 0, STATE C VSA contains A,B,C,D lxvw4x VSR(VSE), TC16, STATE C VSE contains E,F,G,H performance comes back to about where it was before removing the TC loads (parens are compared against the previous run): alg/mode min avg max ====================== ============== ============== ============== sha256 update 468.29 (+5.82) 468.74 (+5.99) 468.86 (+5.99) hmac-sha256 64 bytes 126.51 (+0.50) 127.26 (+0.57) 127.78 (+0.78) hmac-sha256 256 bytes 273.17 (+3.04) 274.51 (+2.89) 276.24 (+3.25) hmac-sha256 1024 bytes 393.27 (+2.48) 395.18 (+3.34) 397.87 (+4.83) hmac-sha256 4096 bytes 441.08 (+2.48) 443.21 (+4.38) 445.09 (+5.79) hmac-sha256 single msg 454.41 (-0.11) 458.30 (+3.67) 460.82 (+6.06) I suspect with four li instructions, those are issued 4x in parallel, and then the subsequent (slower) lxvw4x instructions are queued 2x. By removing the other three li instructions, that li is queued with the first lxvw4x, but not the second -- causing a stall as the second lxv has to wait for the parallel queue of the li + lxv before, as it depends on the li completing first. This is only my running theory, but unfortunately I don't currently have the bandwidth to do a deep dive for a <2% performance mystery (that said, I do intend to return to this when I get the chance, I suspect other areas of the code could also use a similar level of scrutiny). Do you have any thoughts or advice on this, or is the proposed approach acceptable for now? Additional note: I did also try rearranging the LOAD macros with the shifts, as well as moving around the requisite byte-swap vperms, but did not receive any performance benefits. It appears doing the load, vperm, shift, addi in that order appears to be the fastest order. powerpc64/p8/sha256-compress-n.asm | 33 +++++++++++++----------------- 1 file changed, 14 insertions(+), 19 deletions(-) diff --git a/powerpc64/p8/sha256-compress-n.asm b/powerpc64/p8/sha256-compress-n.asm index e08ae132..d3416e2a 100644 --- a/powerpc64/p8/sha256-compress-n.asm +++ b/powerpc64/p8/sha256-compress-n.asm @@ -44,10 +44,7 @@ define(`T1', `r8') define(`TK', `r9') define(`COUNT', `r10') define(`TC0', `0') C Index instructions allow literal 0 instead of a GPR -define(`TC4', `r11') -define(`TC8', `r12') -define(`TC12', `r14') -define(`TC16', `r15') +define(`TC16', `r11') C State registers define(`VSA', `v0') @@ -187,24 +184,24 @@ define(`LOAD', ` define(`DOLOADS', ` IF_LE(`DATA_LOAD_VEC(VT0, .load_swap, T1)') LOAD(0, TC0) - LOAD(1, TC4) - LOAD(2, TC8) - LOAD(3, TC12) + vsldoi IV(1), IV(0), IV(0), 4 + vsldoi IV(2), IV(0), IV(0), 8 + vsldoi IV(3), IV(0), IV(0), 12 addi INPUT, INPUT, 16 LOAD(4, TC0) - LOAD(5, TC4) - LOAD(6, TC8) - LOAD(7, TC12) + vsldoi IV(5), IV(4), IV(4), 4 + vsldoi IV(6), IV(4), IV(4), 8 + vsldoi IV(7), IV(4), IV(4), 12 addi INPUT, INPUT, 16 LOAD(8, TC0) - LOAD(9, TC4) - LOAD(10, TC8) - LOAD(11, TC12) + vsldoi IV(9), IV(8), IV(8), 4 + vsldoi IV(10), IV(8), IV(8), 8 + vsldoi IV(11), IV(8), IV(8), 12 addi INPUT, INPUT, 16 LOAD(12, TC0) - LOAD(13, TC4) - LOAD(14, TC8) - LOAD(15, TC12) + vsldoi IV(13), IV(12), IV(12), 4 + vsldoi IV(14), IV(12), IV(12), 8 + vsldoi IV(15), IV(12), IV(12), 12 addi INPUT, INPUT, 16 ') @@ -245,10 +242,8 @@ PROLOGUE(_nettle_sha256_compress_n) stdx r14, T0, SP stdx r15, T1, SP - li TC4, 4 - li TC8, 8 - li TC12, 12 li TC16, 16 + .align 4 C Load state values lxvw4x VSR(VSA), 0, STATE C VSA contains A,B,C,D -- 2.46.0

2 2

[PATCH] powerpc64/sha256: adjust stack offset for storing non-volatile registers
by Eric Richter 30 Aug '24

30 Aug '24

According to the ABI, the stack pointer is quadword aligned, so starting the stack storage at offset -8, may cause the return address to be stepped on. Adjusting to use -16 as the starting point, which also matches other POWER assembly code. Signed-off-by: Eric Richter <erichte(a)linux.ibm.com> --- powerpc64/p8/sha256-compress-n.asm | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/powerpc64/p8/sha256-compress-n.asm b/powerpc64/p8/sha256-compress-n.asm index 309db1fa..e08ae132 100644 --- a/powerpc64/p8/sha256-compress-n.asm +++ b/powerpc64/p8/sha256-compress-n.asm @@ -216,8 +216,8 @@ PROLOGUE(_nettle_sha256_compress_n) C Store non-volatile registers - li T0, -8 - li T1, -24 + li T0, -16 + li T1, -32 stvx v20, T0, SP stvx v21, T1, SP subi T0, T0, 32 @@ -321,8 +321,8 @@ PROLOGUE(_nettle_sha256_compress_n) C Restore nonvolatile registers - li T0, -8 - li T1, -24 + li T0, -16 + li T1, -32 lvx v20, T0, SP lvx v21, T1, SP subi T0, T0, 32 -- 2.46.0

2 2

[PATCH 1/2] powerpc64: remove use of m4_unquote in the load step for sha256
by Eric Richter 25 Aug '24

25 Aug '24

By passing in the constant offset value into the LOAD macro, the use of m4_unquote to calculate the correct constant GPR can be avoided, improving readability. Signed-off-by: Eric Richter <erichte(a)linux.ibm.com> --- powerpc64/p8/sha256-compress-n.asm | 36 +++++++++++++++--------------- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/powerpc64/p8/sha256-compress-n.asm b/powerpc64/p8/sha256-compress-n.asm index 4848461e..309db1fa 100644 --- a/powerpc64/p8/sha256-compress-n.asm +++ b/powerpc64/p8/sha256-compress-n.asm @@ -177,34 +177,34 @@ define(`EXTENDROUNDS', ` ') define(`LOAD', ` - IF_BE(`lxvw4x VSR(IV($1)), m4_unquote(TC`'eval(($1 % 4) * 4)), INPUT') + IF_BE(`lxvw4x VSR(IV($1)), $2, INPUT') IF_LE(` - lxvd2x VSR(IV($1)), m4_unquote(TC`'eval(($1 % 4) * 4)), INPUT + lxvd2x VSR(IV($1)), $2, INPUT vperm IV($1), IV($1), IV($1), VT0 ') ') define(`DOLOADS', ` IF_LE(`DATA_LOAD_VEC(VT0, .load_swap, T1)') - LOAD(0) - LOAD(1) - LOAD(2) - LOAD(3) + LOAD(0, TC0) + LOAD(1, TC4) + LOAD(2, TC8) + LOAD(3, TC12) addi INPUT, INPUT, 16 - LOAD(4) - LOAD(5) - LOAD(6) - LOAD(7) + LOAD(4, TC0) + LOAD(5, TC4) + LOAD(6, TC8) + LOAD(7, TC12) addi INPUT, INPUT, 16 - LOAD(8) - LOAD(9) - LOAD(10) - LOAD(11) + LOAD(8, TC0) + LOAD(9, TC4) + LOAD(10, TC8) + LOAD(11, TC12) addi INPUT, INPUT, 16 - LOAD(12) - LOAD(13) - LOAD(14) - LOAD(15) + LOAD(12, TC0) + LOAD(13, TC4) + LOAD(14, TC8) + LOAD(15, TC12) addi INPUT, INPUT, 16 ') -- 2.45.2

2 4

[PATCH 0/2] AARCH64 Enable PAC and BTI
by Bill Roberts 13 Aug '24

13 Aug '24

This patchset enables PAC and BTI for nettle. Daiki has a patch here that I gave commented on: - https://git.lysator.liu.se/nettle/nettle/-/merge_requests/65 I also have an open public github with these changes at: https://github.com/billatarm/nettle/pull/1 Overally the patches are very similair, I just chose a different construct in how the various things are propgrated from configure to m4 which I think is a better seperation of duties. I wanted to share these over the mailing list as I am unable to create a fork on the GitLab instance and send a PR that way. Bill Roberts (2): x68_64: move machine specific asm to arch asm.m4 aarch64: enable PAC/BTI arm64/machine.m4 | 57 +++++++++++++++++++++++++++++++++++++++++++++++ asm.m4 | 2 +- config.m4.in | 4 ++++ configure.ac | 43 +++++++++++++++++++++++++++++++++++ x86_64/machine.m4 | 5 +++++ 5 files changed, 110 insertions(+), 1 deletion(-) -- 2.45.2

1 2

nettle: PACBTI for arm64 assembly
by Daiki Ueno 22 Jul '24

22 Jul '24

Hello, The attached is my attempt to enable PAC/BTI[1] support for AArch64. As the Nettle assembly files only define leaf functions (i.e., no subroutine calls with LR/SP save/restore), PAC is not applicable and thus only BTI is enabled for now. To test, I used the mock[2] environment with the fedora-40-aarch64 configuration: $ mock -r fedora-40-aarch64 --init <mock-chroot> sh-5.2# ./.bootstrap <mock-chroot> sh-5.2# ./configure --disable-documentation CFLAGS="-mbranch-protection=standard" <mock-chroot> sh-5.2# make -j$(nproc) <mock-chroot> sh-5.2# readelf -n libnettle.so Displaying notes found in: .note.gnu.property Owner Data size Description GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0 Properties: AArch64 feature: BTI, PAC ... Regards, Footnotes: [1] https://wiki.debian.org/ToolChain/PACBTI [2] https://fedoraproject.org/wiki/Using_Mock_to_test_package_builds -- Daiki Ueno

3 7

[PATCH v3] powerpc64: Add optimized assembly for sha256-compress-n
by Eric Richter 18 Jun '24

18 Jun '24

This patch introduces an optimized powerpc64 assembly implementation for sha256-compress-n. This takes advantage of the vshasigma instruction, as well as unrolling loops to best take advantage of running instructions in parallel. The following data was captured on a POWER 10 LPAR @ ~3.896GHz Current C implementation: Algorithm mode Mbyte/s sha256 update 280.97 hmac-sha256 64 bytes 80.81 hmac-sha256 256 bytes 170.50 hmac-sha256 1024 bytes 241.92 hmac-sha256 4096 bytes 268.54 hmac-sha256 single msg 276.16 With optimized assembly: Algorithm mode Mbyte/s sha256 update 461.45 hmac-sha256 64 bytes 123.88 hmac-sha256 256 bytes 268.81 hmac-sha256 1024 bytes 390.91 hmac-sha256 4096 bytes 438.02 hmac-sha256 single msg 453.83 Signed-off-by: Eric Richter <erichte(a)linux.ibm.com> --- I split this patch to be standalone, rather than delay even further trying to update SHA512 -- I will update the SHA512 implementation when this one stabilizes. Regarding the load vperm needed for little endian: unfortunately we don't have a spare vector register to store the mask between rounds, so the best that can be done while maintaining p8 support will be to store the mask in a VSX register like the state values, and avoid the load. This is a negligible performance change however, yielding around +1MB/s on larger block counts (update, hmac 1024/4096/single msg) and -1MB/s on smaller (hmac 64/256). Dropping p8 support allows the use of the lxvb16x instruction, which does not need to be permuted, however that is as well a negligible performance improvement at the cost of dropping a whole cpu set. So I see a few options: A) leave as-is, consider storing the mask in a VSX register B) drop p8 support, use lxvb16x C) have a compile-time switch to use permute on p8, and use the single instruction for p9 an up. v3: - use protected zone instead of allocating stack space - add GPRs constants for multiples of 4 for loads - around +3.4 MB/s for sha256 update - move extend logic to its own macro called by EXTENDROUND - use 8 VSX registers to store previous state instead of the stack - around +11.0 MB/s for sha256 update fat-ppc.c | 12 + powerpc64/fat/sha256-compress-n-2.asm | 36 +++ powerpc64/p8/sha256-compress-n.asm | 364 ++++++++++++++++++++++++++ 3 files changed, 412 insertions(+) create mode 100644 powerpc64/fat/sha256-compress-n-2.asm create mode 100644 powerpc64/p8/sha256-compress-n.asm diff --git a/fat-ppc.c b/fat-ppc.c index cd76f7a1..efbeb2ec 100644 --- a/fat-ppc.c +++ b/fat-ppc.c @@ -203,6 +203,10 @@ DECLARE_FAT_FUNC(_nettle_poly1305_blocks, poly1305_blocks_func) DECLARE_FAT_FUNC_VAR(poly1305_blocks, poly1305_blocks_func, c) DECLARE_FAT_FUNC_VAR(poly1305_blocks, poly1305_blocks_func, ppc64) +DECLARE_FAT_FUNC(_nettle_sha256_compress_n, sha256_compress_n_func) +DECLARE_FAT_FUNC_VAR(sha256_compress_n, sha256_compress_n_func, c) +DECLARE_FAT_FUNC_VAR(sha256_compress_n, sha256_compress_n_func, ppc64) + static void CONSTRUCTOR fat_init (void) @@ -231,6 +235,8 @@ fat_init (void) _nettle_ghash_update_arm64() */ _nettle_ghash_set_key_vec = _nettle_ghash_set_key_ppc64; _nettle_ghash_update_vec = _nettle_ghash_update_ppc64; + + _nettle_sha256_compress_n_vec = _nettle_sha256_compress_n_ppc64; } else { @@ -239,6 +245,7 @@ fat_init (void) _nettle_aes_invert_vec = _nettle_aes_invert_c; _nettle_ghash_set_key_vec = _nettle_ghash_set_key_c; _nettle_ghash_update_vec = _nettle_ghash_update_c; + _nettle_sha256_compress_n_vec = _nettle_sha256_compress_n_c; } if (features.have_altivec) { @@ -338,3 +345,8 @@ DEFINE_FAT_FUNC(_nettle_poly1305_blocks, const uint8_t *, size_t blocks, const uint8_t *m), (ctx, blocks, m)) + +DEFINE_FAT_FUNC(_nettle_sha256_compress_n, const uint8_t *, + (uint32_t *state, const uint32_t *k, + size_t blocks, const uint8_t *input), + (state, k, blocks, input)) diff --git a/powerpc64/fat/sha256-compress-n-2.asm b/powerpc64/fat/sha256-compress-n-2.asm new file mode 100644 index 00000000..4f4eee9d --- /dev/null +++ b/powerpc64/fat/sha256-compress-n-2.asm @@ -0,0 +1,36 @@ +C powerpc64/fat/sha256-compress-n-2.asm + +ifelse(` + Copyright (C) 2024 Eric Richter, IBM Corporation + + This file is part of GNU Nettle. + + GNU Nettle is free software: you can redistribute it and/or + modify it under the terms of either: + + * the GNU Lesser General Public License as published by the Free + Software Foundation; either version 3 of the License, or (at your + option) any later version. + + or + + * the GNU General Public License as published by the Free + Software Foundation; either version 2 of the License, or (at your + option) any later version. + + or both in parallel, as here. + + GNU Nettle is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + General Public License for more details. + + You should have received copies of the GNU General Public License and + the GNU Lesser General Public License along with this program. If + not, see http://www.gnu.org/licenses/. +') + +dnl PROLOGUE(_nettle_sha256_compress_n) picked up by configure + +define(`fat_transform', `$1_ppc64') +include_src(`powerpc64/p8/sha256-compress-n.asm') diff --git a/powerpc64/p8/sha256-compress-n.asm b/powerpc64/p8/sha256-compress-n.asm new file mode 100644 index 00000000..c1ce0e8f --- /dev/null +++ b/powerpc64/p8/sha256-compress-n.asm @@ -0,0 +1,364 @@ +C x86_64/sha256-compress-n.asm + +ifelse(` + Copyright (C) 2024 Eric Richter, IBM Corporation + + This file is part of GNU Nettle. + + GNU Nettle is free software: you can redistribute it and/or + modify it under the terms of either: + + * the GNU Lesser General Public License as published by the Free + Software Foundation; either version 3 of the License, or (at your + option) any later version. + + or + + * the GNU General Public License as published by the Free + Software Foundation; either version 2 of the License, or (at your + option) any later version. + + or both in parallel, as here. + + GNU Nettle is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + General Public License for more details. + + You should have received copies of the GNU General Public License and + the GNU Lesser General Public License along with this program. If + not, see http://www.gnu.org/licenses/. +') + +.file "sha256-compress-n.asm" + +C Parameters in +define(`SP', `r1') +define(`STATE', `r3') +define(`K', `r4') +define(`NUMBLOCKS', `r5') +define(`INPUT', `r6') + +define(`T0', `r7') +define(`T1', `r8') +define(`TK', `r9') +define(`COUNT', `r10') +define(`TC0', `0') C Index instructions allow literal 0 instead of a GPR +define(`TC4', `r11') +define(`TC8', `r12') +define(`TC12', `r14') +define(`TC16', `r15') + +C State registers +define(`VSA', `v0') +define(`VSB', `v1') +define(`VSC', `v2') +define(`VSD', `v3') +define(`VSE', `v4') +define(`VSF', `v5') +define(`VSG', `v6') +define(`VSH', `v7') + +C Previous state value registers stored in VSX +define(`VSXA', `vs0') +define(`VSXB', `vs1') +define(`VSXC', `vs2') +define(`VSXD', `vs3') +define(`VSXE', `vs4') +define(`VSXF', `vs5') +define(`VSXG', `vs6') +define(`VSXH', `vs7') + +C Current K values +define(`VK', `v8') + +C Temp registers for math +define(`VT0', `v9') +define(`VT1', `v10') +define(`VT2', `v11') +define(`VT3', `v12') +define(`VT4', `v13') + +C Convenience named registers for sigma(a) and sigma(e) +define(`SIGA', `v14') +define(`SIGE', `v15') + +C Registers v16-v31 are used for input words W[0] through W[15] + +C Convert an index for W[i] to the corresponding vector register v[16 + i] +define(`IV', `m4_unquote(v`'eval((($1) % 16) + 16))') + +C ROUND(A B C D E F G H R EXT) +define(`ROUND', ` + + vadduwm VT1, VK, IV($9) C VT1: k+W + vadduwm VT4, $8, VT1 C VT4: H+k+W + + lxvw4x VSR(VK), TK, K C Load Key + addi TK, TK, 4 C Increment Pointer to next key + + vadduwm VT2, $4, $8 C VT2: H+D + vadduwm VT2, VT2, VT1 C VT2: H+D+k+W + + vshasigmaw SIGE, $5, 1, 0b1111 C Sigma(E) Se + vshasigmaw SIGA, $1, 1, 0 C Sigma(A) Sa + + vxor VT3, $2, $3 C VT3: b^c + vsel VT0, $7, $6, $5 C VT0: Ch. + vsel VT3, $3, $1, VT3 C VT3: Maj(a,b,c) + + vadduwm VT4, VT4, VT0 C VT4: Hkw + Ch. + vadduwm VT3, VT3, VT4 C VT3: HkW + Ch. + Maj. + + vadduwm VT0, VT0, VT2 C VT0: Ch. + DHKW + vadduwm $8, SIGE, SIGA C Anext: Se + Sa + vadduwm $4, VT0, SIGE C Dnext: Ch. + DHKW + Se + vadduwm $8, $8, VT3 C Anext: Se+Sa+HkW+Ch.+Maj. +') + +C Extend W[i] +define(`EXTEND', ` + vshasigmaw SIGE, IV($1 + 14), 0, 0b1111 + vshasigmaw SIGA, IV($1 + 1), 0, 0b0000 + vadduwm IV($1), IV($1), SIGE + vadduwm IV($1), IV($1), SIGA + vadduwm IV($1), IV($1), IV($1 + 9) +') + +define(`EXTENDROUND', ` + ROUND($1, $2, $3, $4, $5, $6, $7, $8, $9) + C Schedule (data) for 16th round in future + EXTEND($9) +') +define(`NOEXTENDROUND', `ROUND($1, $2, $3, $4, $5, $6, $7, $8, $9)') + +define(`NOEXTENDROUNDS', ` + NOEXTENDROUND(VSA, VSB, VSC, VSD, VSE, VSF, VSG, VSH, 0) + NOEXTENDROUND(VSH, VSA, VSB, VSC, VSD, VSE, VSF, VSG, 1) + NOEXTENDROUND(VSG, VSH, VSA, VSB, VSC, VSD, VSE, VSF, 2) + NOEXTENDROUND(VSF, VSG, VSH, VSA, VSB, VSC, VSD, VSE, 3) + + NOEXTENDROUND(VSE, VSF, VSG, VSH, VSA, VSB, VSC, VSD, 4) + NOEXTENDROUND(VSD, VSE, VSF, VSG, VSH, VSA, VSB, VSC, 5) + NOEXTENDROUND(VSC, VSD, VSE, VSF, VSG, VSH, VSA, VSB, 6) + NOEXTENDROUND(VSB, VSC, VSD, VSE, VSF, VSG, VSH, VSA, 7) + + NOEXTENDROUND(VSA, VSB, VSC, VSD, VSE, VSF, VSG, VSH, 8) + NOEXTENDROUND(VSH, VSA, VSB, VSC, VSD, VSE, VSF, VSG, 9) + NOEXTENDROUND(VSG, VSH, VSA, VSB, VSC, VSD, VSE, VSF, 10) + NOEXTENDROUND(VSF, VSG, VSH, VSA, VSB, VSC, VSD, VSE, 11) + + NOEXTENDROUND(VSE, VSF, VSG, VSH, VSA, VSB, VSC, VSD, 12) + NOEXTENDROUND(VSD, VSE, VSF, VSG, VSH, VSA, VSB, VSC, 13) + NOEXTENDROUND(VSC, VSD, VSE, VSF, VSG, VSH, VSA, VSB, 14) + NOEXTENDROUND(VSB, VSC, VSD, VSE, VSF, VSG, VSH, VSA, 15) +') + +define(`EXTENDROUNDS', ` + EXTENDROUND(VSA, VSB, VSC, VSD, VSE, VSF, VSG, VSH, 0) + EXTENDROUND(VSH, VSA, VSB, VSC, VSD, VSE, VSF, VSG, 1) + EXTENDROUND(VSG, VSH, VSA, VSB, VSC, VSD, VSE, VSF, 2) + EXTENDROUND(VSF, VSG, VSH, VSA, VSB, VSC, VSD, VSE, 3) + + EXTENDROUND(VSE, VSF, VSG, VSH, VSA, VSB, VSC, VSD, 4) + EXTENDROUND(VSD, VSE, VSF, VSG, VSH, VSA, VSB, VSC, 5) + EXTENDROUND(VSC, VSD, VSE, VSF, VSG, VSH, VSA, VSB, 6) + EXTENDROUND(VSB, VSC, VSD, VSE, VSF, VSG, VSH, VSA, 7) + + EXTENDROUND(VSA, VSB, VSC, VSD, VSE, VSF, VSG, VSH, 8) + EXTENDROUND(VSH, VSA, VSB, VSC, VSD, VSE, VSF, VSG, 9) + EXTENDROUND(VSG, VSH, VSA, VSB, VSC, VSD, VSE, VSF, 10) + EXTENDROUND(VSF, VSG, VSH, VSA, VSB, VSC, VSD, VSE, 11) + + EXTENDROUND(VSE, VSF, VSG, VSH, VSA, VSB, VSC, VSD, 12) + EXTENDROUND(VSD, VSE, VSF, VSG, VSH, VSA, VSB, VSC, 13) + EXTENDROUND(VSC, VSD, VSE, VSF, VSG, VSH, VSA, VSB, 14) + EXTENDROUND(VSB, VSC, VSD, VSE, VSF, VSG, VSH, VSA, 15) +') + +define(`LOAD', ` + IF_BE(`lxvw4x VSR(IV($1)), m4_unquote(TC`'eval(($1 % 4) * 4)), INPUT') + IF_LE(` + lxvd2x VSR(IV($1)), m4_unquote(TC`'eval(($1 % 4) * 4)), INPUT + vperm IV($1), IV($1), IV($1), VT0 + ') +') + +define(`DOLOADS', ` + IF_LE(`DATA_LOAD_VEC(VT0, .load_swap, T1)') + LOAD(0) + LOAD(1) + LOAD(2) + LOAD(3) + addi INPUT, INPUT, 16 + LOAD(4) + LOAD(5) + LOAD(6) + LOAD(7) + addi INPUT, INPUT, 16 + LOAD(8) + LOAD(9) + LOAD(10) + LOAD(11) + addi INPUT, INPUT, 16 + LOAD(12) + LOAD(13) + LOAD(14) + LOAD(15) + addi INPUT, INPUT, 16 +') + +.text +PROLOGUE(_nettle_sha256_compress_n) + cmpwi 0, NUMBLOCKS, 0 + ble 0, .done + mtctr NUMBLOCKS + + C Store non-volatile registers + + li T0, -8 + li T1, -24 + stvx v20, T0, SP + stvx v21, T1, SP + subi T0, T0, 32 + subi T1, T1, 32 + stvx v22, T0, SP + stvx v23, T1, SP + subi T0, T0, 32 + subi T1, T1, 32 + stvx v24, T0, SP + stvx v25, T1, SP + subi T0, T0, 32 + subi T1, T1, 32 + stvx v26, T0, SP + stvx v27, T1, SP + subi T0, T0, 32 + subi T1, T1, 32 + stvx v28, T0, SP + stvx v29, T1, SP + subi T0, T0, 32 + subi T1, T1, 32 + stvx v30, T0, SP + stvx v31, T1, SP + subi T0, T0, 32 + subi T1, T1, 32 + stdx r14, T0, SP + stdx r15, T1, SP + + li TC4, 4 + li TC8, 8 + li TC12, 12 + li TC16, 16 + + C Load state values + lxvw4x VSR(VSA), 0, STATE C VSA contains A,B,C,D + lxvw4x VSR(VSE), TC16, STATE C VSE contains E,F,G,H + + vsldoi VSB, VSA, VSA, 4 + vsldoi VSF, VSE, VSE, 4 + + vsldoi VSC, VSA, VSA, 8 + vsldoi VSG, VSE, VSE, 8 + + vsldoi VSD, VSA, VSA, 12 + vsldoi VSH, VSE, VSE, 12 + +.loop: + xxlor VSXA, VSR(VSA), VSR(VSA) + xxlor VSXB, VSR(VSB), VSR(VSB) + xxlor VSXC, VSR(VSC), VSR(VSC) + xxlor VSXD, VSR(VSD), VSR(VSD) + xxlor VSXE, VSR(VSE), VSR(VSE) + xxlor VSXF, VSR(VSF), VSR(VSF) + xxlor VSXG, VSR(VSG), VSR(VSG) + xxlor VSXH, VSR(VSH), VSR(VSH) + + li TK, 0 + lxvw4x VSR(VK), TK, K + addi TK, TK, 4 + + DOLOADS + + C "permute" state from VSA containing A,B,C,D into VSA,VSB,VSC,VSD + + EXTENDROUNDS + EXTENDROUNDS + EXTENDROUNDS + NOEXTENDROUNDS + + C Reload initial state from VSX registers + xxlor VSR(VT0), VSXA, VSXA + xxlor VSR(VT1), VSXB, VSXB + xxlor VSR(VT2), VSXC, VSXC + xxlor VSR(VT3), VSXD, VSXD + xxlor VSR(VT4), VSXE, VSXE + xxlor VSR(SIGA), VSXF, VSXF + xxlor VSR(SIGE), VSXG, VSXG + xxlor VSR(VK), VSXH, VSXH + + vadduwm VSA, VSA, VT0 + vadduwm VSB, VSB, VT1 + vadduwm VSC, VSC, VT2 + vadduwm VSD, VSD, VT3 + vadduwm VSE, VSE, VT4 + vadduwm VSF, VSF, SIGA + vadduwm VSG, VSG, SIGE + vadduwm VSH, VSH, VK + + bdnz .loop + + C Repack VSA,VSB,VSC,VSD into VSA,VSE for storing + vmrghw VSA, VSA, VSB + vmrghw VSC, VSC, VSD + vmrghw VSE, VSE, VSF + vmrghw VSG, VSG, VSH + + xxmrghd VSR(VSA), VSR(VSA), VSR(VSC) + xxmrghd VSR(VSE), VSR(VSE), VSR(VSG) + + stxvw4x VSR(VSA), 0, STATE + stxvw4x VSR(VSE), TC16, STATE + + + C Restore nonvolatile registers + li T0, -8 + li T1, -24 + lvx v20, T0, SP + lvx v21, T1, SP + subi T0, T0, 32 + subi T1, T1, 32 + lvx v22, T0, SP + lvx v23, T1, SP + subi T0, T0, 32 + subi T1, T1, 32 + lvx v24, T0, SP + lvx v25, T1, SP + subi T0, T0, 32 + subi T1, T1, 32 + lvx v26, T0, SP + lvx v27, T1, SP + subi T0, T0, 32 + subi T1, T1, 32 + lvx v28, T0, SP + lvx v29, T1, SP + subi T0, T0, 32 + subi T1, T1, 32 + lvx v30, T0, SP + lvx v31, T1, SP + subi T0, T0, 32 + subi T1, T1, 32 + ldx r14, T0, SP + ldx r15, T1, SP + +.done: + mr r3, INPUT + + blr +EPILOGUE(_nettle_sha256_compress_n) + +IF_LE(` +.data +.align 4 +.load_swap: + .byte 8,9,10,11, 12,13,14,15, 0,1,2,3, 4,5,6,7 +') -- 2.45.0

2 4

ANNOUNCE: Nettle-3.10
by Niels Möller 16 Jun '24

16 Jun '24

I'm happy to announce a new release of GNU Nettle, a low-level cryptographics library. This release adds support for RSA-OAEP, and improves performance mainly for powerpc64. See NEWS entries below. The Nettle home page can be found at https://www.lysator.liu.se/~nisse/nettle/, and the manual at https://www.lysator.liu.se/~nisse/nettle/nettle.html. The release can be downloaded from https://ftp.gnu.org/gnu/nettle/nettle-3.10.tar.gz https://www.lysator.liu.se/~nisse/archive/nettle-3.10.tar.gz Happy hacking, /Niels Möller NEWS for the Nettle 3.10 release This is a maintenance release, including a few each of bug fixes, new features and optimizations. The new version is intended to be fully source and binary compatible with Nettle-3.6. The shared library names are libnettle.so.8.9 and libhogweed.so.6.9, with sonames libnettle.so.8 and libhogweed.so.6. Bug fixes: * Add missing hash functions sha512_224 and sha512_256 to the nettle_get_hashes() list. The name values in the corresponding nettle_hash structs also changed to use underscore instead of dash, for consistency. * Fix a few cases of formally undefined calls to memcpy(dst, NULL, 0), resulting from valid calls to, e.g., sha256_update(ctx, 0, NULL). New features: * Support RSA-OAEP encryption. Contributed by Nicolas Mora and Daiki Ueno. * New function sha3_256_shake_output, new functions sha3_128_init, sha3_128_update, sha3_128_shake, sha3_128_shake_output. Contributed by Daiki Ueno. * Added DRBG-CTR with AES256, contributed by Simon Josefsson. Optimizations: * New combined gcm-aes assembly for powerpc64, contributed by Danny Tsen. * New sha256 assembly for powerpc64, contributed by Eric Richter. * Improved performance for powerpc64 AES decrypt, by skipping subkey transformations that don't suit the vncipher instructions. * Add arm64 CPU feature detection for Android and for Apple systems, contributed by Foolbar and Tim Kosse, prespectively. Miscellaneous: * New tests for side-channel silence, based on valgrind. * Delete all md5 assembly code. Delete all sparc32 assembly code. -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

1 0

Nettle release plans
by Niels Möller 16 Jun '24

16 Jun '24

I'm thinking about Nettle releases. I think it would be nice to get out a maintenance 3.10 release before summer vacations. (current NEWS file at https://git.lysator.liu.se/nettle/nettle/-/blob/master/NEWS is fairly accurate). After that, there are two different directions: * Try to clean up some of the API issues. This will break the API (and like for previous changes, it could make sense to add foo-compat.h include files that supports old API, to make it easy to upgrade an application to work with the new nettle version, while incrementally adjusting to the new api). It may also break ABI and imply an soname change, or we could keep old symbols working for the case of old applications linking to new libnettle.so (but not the other way round, as documented at https://www.lysator.liu.se/~nisse/nettle/nettle.html#Compatibility). If we go this way, that would be a Nettle-4.0, and it would make sense to me to try to get that done without much new features, and without making it a huge long-term project. * Focus on getting post-quantum algorithms into Nettle. What do you think? Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

3 6

[PATCH] arm64: CPU feature detection for Android
by Foolbar 12 Jun '24

12 Jun '24

getauxval() is available on Android since API 18. https://developer.android.com/ndk/guides/cpu-features#features_using_libcs_… --- fat-arm64.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/fat-arm64.c b/fat-arm64.c index 240302a6..45cce0cc 100644 --- a/fat-arm64.c +++ b/fat-arm64.c @@ -43,9 +43,14 @@ #if defined(__linux__) && defined(__GLIBC__) && defined(__GLIBC_PREREQ) # if __GLIBC_PREREQ(2, 16) # define USE_GETAUXVAL 1 -# include <asm/hwcap.h> -# include <sys/auxv.h> # endif +#elif __ANDROID_API__ >= 18 +# define USE_GETAUXVAL 1 +#endif + +#if USE_GETAUXVAL +# include <asm/hwcap.h> +# include <sys/auxv.h> #elif defined(__OpenBSD__) # include <sys/sysctl.h> # include <machine/cpu.h> -- 2.34.1

3 2

Deterministic (EC)DSA
by Daiki Ueno 22 May '24

22 May '24

Hello, The attached patch adds support for the deterministic DSA and ECDSA, as defined in RFC 6979, which enables us to use the signing function without randomness. The original code has been hosted in GnuTLS for a while, implemented as a custom random function which can be used in combination with dsa_sign and ecdsa_sign. While this approach works in general, it requires pre/post processing: e.g., access to ECC q[1] and cancelling out the Nettle's tweak in dsa_sign adding 1[2] to the random value. Therefore, I would rather like this to be included in Nettle itself. Note also that this implementation should be identical to the latest code in GnuTLS, which addresses the Minerva attack[3]. The same patch is also available at GitLab: https://git.lysator.liu.se/nettle/nettle/-/merge_requests/64 Footnotes: [1] https://gitlab.com/gnutls/gnutls/-/blob/c1428c07d406f18cca94f94e2b7ca1f866d… [2] https://gitlab.com/gnutls/gnutls/-/blob/c1428c07d406f18cca94f94e2b7ca1f866d… [3] https://nvd.nist.gov/vuln/detail/CVE-2024-28834 Regards, -- Daiki Ueno

2 7

[PATCH v2 0/2] Add optimized powerpc64 assembly for SHA2
by Eric Richter 07 May '24

07 May '24

I've updated this set to use the proper conventions for register names, and also adjusted the IV macro according to the suggestions provided. I can also confirm that I've gotten a working build environment based on the approach the GitLab CI configuration, and that the ppc64 big-endian build does indeed pass tests. Amended original cover letter: This set introduces an optimized powerpc64 assembly implementation for SHA256 and SHA512. This have been derived from BSD-2-Clause licensed code authored by IBM, originally released in the IBM POWER Cryptography Reference Implementation project[1], modified to work in Nettle, contributed under the GPL license. Development of this new implementation targetted POWER 10, however supports the POWER 8 and above ISA. The following commits provide the performance data I recorded on POWER 10, though similar improvements can be found on P8/P9. I have tested this patch set on POWER 8 and POWER 10, hardware running little-endian linux distributions, and via qemu-user for big-endian ppc64. Eric Richter (2): powerpc64: Add optimized assembly for sha256-compress-n powerpc64: Add optimized assembly for sha512-compress-n fat-ppc.c | 22 ++ powerpc64/fat/sha256-compress-n-2.asm | 36 +++ powerpc64/fat/sha512-compress-2.asm | 36 +++ powerpc64/p8/sha256-compress-n.asm | 323 +++++++++++++++++++++++++ powerpc64/p8/sha512-compress.asm | 327 ++++++++++++++++++++++++++ 5 files changed, 744 insertions(+) create mode 100644 powerpc64/fat/sha256-compress-n-2.asm create mode 100644 powerpc64/fat/sha512-compress-2.asm create mode 100644 powerpc64/p8/sha256-compress-n.asm create mode 100644 powerpc64/p8/sha512-compress.asm -- 2.44.0

2 4

[PATCH 0/2] Add optimized powerpc64 assembly for SHA2
by Eric Richter 17 Apr '24

17 Apr '24

This set introduces an optimized powerpc64 assembly implementation for SHA256 and SHA512. This have been derived from BSD-2-Clause licensed code authored by IBM, originally released in the IBM POWER Cryptography Reference Implementation project[1], modified to work in Nettle, contributed under the GPL license. Development of this new implementation targetted POWER 10, however supports the POWER 8 ISA and above. The following commits provide the performance data I recorded on POWER 10, though similar improvements can be found on P8/P9. As an aside: I have tested this patch set on POWER 8 and POWER 10 hardware running little-endian linux distributions, however I have not yet been able to test on a big-endian distro. I can confirm however that the original source in IPCRI does compile and pass tests for both little and big endian via qemu-user, so spare human error in deriving the version for Nettle, it is expected to be functional. [1] https://github.com/ibm/ipcri Eric Richter (2): powerpc64: Add optimized assembly for sha256-compress-n powerpc64: Add optimized assembly for sha512-compress-n powerpc64/p8/sha256-compress-n.asm | 339 ++++++++++++++++++++++++++++ powerpc64/p8/sha512-compress.asm | 345 +++++++++++++++++++++++++++++ 2 files changed, 684 insertions(+) create mode 100644 powerpc64/p8/sha256-compress-n.asm create mode 100644 powerpc64/p8/sha512-compress.asm -- 2.43.0

2 7

ppc64 micro optimization
by Niels Möller 14 Apr '24

14 Apr '24

In preparing for merging the gcm-aes "stitched" implementation, I'm reviewing the existing ghash code. WIP branch "ppc-ghash-macros. I've introduced a macro GHASH_REDUCE, for the reduction logic. Besides that, I've been able to improve scheduling of the reduction instructions (adding in the result of vpmsumd last seems to improve parallelism, some 3% speedup of gcm_update on power10, benchmarked on cfarm120). I've also streamlined the way load offsets are used, and trimmed the number of needed vector registers slightly. For the AES code, I've merged the new macros (I settled on the names OPN_XXY and OPN_XXXY), no change in speed expected from that change. I've also tried to understand the differenct between AES encrypt and decrypt, where decrypt is much slower, and uses an extra xor instruction in the round loop. I think the reason for that is that other AES implementations (including x86_64 and arm64 instructions, and Nettle's C implementation) expect the decryption subkeys to be transformed via the AES "MIX_COLUMN" operation, see https://gitlab.com/gnutls/nettle/-/blob/master/aes-invert-internal.c?ref_ty… While the powerpc64 vncipher instruction really wants the original subkeys, not transformed. So on power, it would be better to have a _nettle_aes_invert that is essentially a memcpy, and then the aes decrypt assembly code could be reworked without the xors, and run at exactly the same speed as encryption. Current _nettle_aes_invert also changes the order of the subkeys, with a FIXME comment suggesting that it would be better to update the order keys are accessed in the aes decryption functions. Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

2 17

additional API for SHAKE streaming read
by Daiki Ueno 14 Apr '24

14 Apr '24

Hello, When I'm trying to implement ML-KEM (Kyber), I realized that the current API for SHAKE (sha3_256_shake) is a bit too limited: while ML-KEM uses SHAKE128 as a source of pseudorandom samples[1], the the current API requires the total number of bytes are determined prior to the call, and after the call the hash context is reset. Here I propose adding a couple of helper functions to support such streaming use-case: sha3_256_shake_pad to process the final block, and sha3_256_shake_read to read the digest from the current state without resetting the context. With those functions, one could write a streaming read interface as attached. What do you think? The actual code changes can be found at: https://git.lysator.liu.se/nettle/nettle/-/merge_requests/61 I also have a SHAKE128 implementation with analogous API, which I will post later. Regards, Footnotes: [1] https://bwesterb.github.io/draft-schwabe-cfrg-kyber/draft-cfrg-schwabe-kybe… -- Daiki Ueno #include "sha3.h" #include <stdio.h> struct shake_reader { struct sha3_256_ctx ctx; uint8_t buf[SHA3_256_BLOCK_SIZE]; size_t offset; }; static void shake_reader_init (struct shake_reader *reader) { sha3_256_init (&reader->ctx); reader->offset = sizeof(reader->buf); } static void shake_reader_read (struct shake_reader *reader, size_t length, uint8_t *digest) { while (length > 0) { while (reader->offset < sizeof(reader->buf)) { *digest++ = reader->buf[reader->offset++]; length--; if (!length) return; } if (reader->offset == sizeof(reader->buf)) { sha3_256_shake_read (&reader->ctx, sizeof(reader->buf), reader->buf); sha3_permute (&reader->ctx.state); reader->offset = 0; } } } int main (void) { struct shake_reader reader; uint8_t buf[3]; size_t n = 0; shake_reader_init (&reader); sha3_256_update (&reader.ctx, 0, NULL); sha3_256_shake_pad (&reader.ctx); while (n < 256) { shake_reader_read (&reader, sizeof(buf), buf); int d1 = buf[0] + 256 * (buf[1] % 16); int d2 = (buf[1] >> 4) + 16 * buf[2]; if (d1 < 3329) { printf ("%d\n", d1); n++; } if (n == 256) break; if (d2 < 3329) { printf ("%d\n", d2); n++; } } return 0; }

2 16

Issue tracker
by Niels Möller 29 Mar '24

29 Mar '24

Hi, I've enabled the issue tracker at https://git.lysator.liu.se/nettle/nettle/-/issues, and filed a few issues for old TODO items, most of which imply ABI and/or API changes. Feel free to file aditional issues for bugs, feature requests, or to track work you are doing or planning. My intention is to (i) keep track of desirable or in-progress changes, and (ii) use for release planning, e.g., use a tag or "milestone" to attach to issues that we want to be included in the next release, similar to how misc/plan.html has been use for some of the releases in the past. Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

1 0

Naming for names in struct nettle_hash
by Niels Möller 28 Mar '24

28 Mar '24

Hi, I've got a bug report that sha512_224 and sha512_256 are missing in the list returned by nettle_get_hashes, and I'm about to add them. But then there's a question of naming convention. Currently, the extern const struct nettle_hash nettle_sha512_256; includes a name field set to the string "sha512-256", which is somewhat inconsistent with, e.g., the struct nettle_sha3_256 which includes the name "sha3_256". Should I just change this (patch below)? Honestly, I haven't given much thought to the conventions used here, but perhaps it makes the most sense that naming match the names of corresponding C symbols (with underscore rather than dash)? Regards, /Niels diff --git a/nettle-meta-hashes.c b/nettle-meta-hashes.c index 4d421182..2245dfb7 100644 --- a/nettle-meta-hashes.c +++ b/nettle-meta-hashes.c @@ -49,6 +49,8 @@ const struct nettle_hash * const _nettle_hashes[] = { &nettle_sha256, &nettle_sha384, &nettle_sha512, + &nettle_sha512_224, + &nettle_sha512_256, &nettle_sha3_224, &nettle_sha3_256, &nettle_sha3_384, diff --git a/sha512-224-meta.c b/sha512-224-meta.c index 24c42bfc..f3751e14 100644 --- a/sha512-224-meta.c +++ b/sha512-224-meta.c @@ -39,7 +39,7 @@ const struct nettle_hash nettle_sha512_224 = { - "sha512-224", sizeof(struct sha512_ctx), + "sha512_224", sizeof(struct sha512_ctx), SHA512_224_DIGEST_SIZE, SHA512_224_BLOCK_SIZE, (nettle_hash_init_func *) sha512_224_init, diff --git a/sha512-256-meta.c b/sha512-256-meta.c index 37d17c35..181f2874 100644 --- a/sha512-256-meta.c +++ b/sha512-256-meta.c @@ -39,7 +39,7 @@ const struct nettle_hash nettle_sha512_256 = { - "sha512-256", sizeof(struct sha512_ctx), + "sha512_256", sizeof(struct sha512_ctx), SHA512_256_DIGEST_SIZE, SHA512_256_BLOCK_SIZE, (nettle_hash_init_func *) sha512_256_init, diff --git a/testsuite/meta-hash-test.c b/testsuite/meta-hash-test.c index 6a15e7db..ec4e0d1e 100644 --- a/testsuite/meta-hash-test.c +++ b/testsuite/meta-hash-test.c @@ -16,6 +16,8 @@ const char* hashes[] = { "sha256", "sha384", "sha512", + "sha512_224", + "sha512_256", "sha3_224", "sha3_256", "sha3_384", -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

1 1

Adding MD5/SHA1 support to RSA OAEP
by Hans Leidekker 27 Mar '24

27 Mar '24

Hello, I noticed the arrival of an RSA OAEP implementation in GnuTLS and wanted to use that to support the algorithm in Wine. Windows supports it using the old MD5 and SHA1 hash functions, so my question is: would you accept a patch like below that adds these hashes?

2 4

HPKE ready for Merge!
by Ajit singh 24 Mar '24

24 Mar '24

Hi all, I trust this message finds you well. Notably, HPKE has already been successfully implemented, and now your prompt attention is sought for the critical review and merging of the MR into the main branch of Nettle. As encrypted client hello(ECH) also relies on HPKE, your swift action is highly appreciated. HPKE MR Link:https://git.lysator.liu.se/nettle/nettle/-/merge_requests/27 Thanks, Ajit

3 4

Relax blocking requirement of gcm_update?
by Niels Möller 10 Mar '24

10 Mar '24

While looking at extended tests of the aead update function (for the associated data), I stumbled on a restriction of gcm_update that is different from most (all?) other update functions in Nettle. According to the docs, -- Function: void gcm_update (struct gcm_ctx *CTX, const struct gcm_key *KEY, size_t LENGTH, const uint8_t *DATA) Provides associated data to be authenticated. If used, must be called before ‘gcm_encrypt’ or ‘gcm_decrypt’. All but the last call for each message _must_ use a length that is a multiple of the block size. Would it be worthwhile to drop the restriction of the last sentence, and allow all calls to gcm_update to use any size? This requirement may be particularly surprising when using nettle_aead; then gcm has different requirements for the update function than all other aead algorithms. I think that might be doable without any ABI break, by the following hack: reuse the ctr field of struct gcm_context as a block buffer, while processing the associated data. The ctr field is clearly needed also for encrypt/decrypt, but we could move initialization for that purpose from gcm_set_iv to the first call to encrypt/decrypt. Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

2 3

Add RSA-OAEP encryption/decryption to Nettle
by Nicolas Mora 09 Mar '24

09 Mar '24

Hello, I've made a new Merge Request in the nettle gitlab repo to provide RSA-OAEP encryption and decryption: https://git.lysator.liu.se/nettle/nettle/-/merge_requests/20 It adds 2 new functions: int pkcs1_oaep_encrypt (size_t key_size, void *random_ctx, nettle_random_func *random, size_t hlen, size_t label_length, const uint8_t *label, size_t message_length, const uint8_t *message, mpz_t m); int pkcs1_oaep_decrypt (size_t key_size, const mpz_t m, size_t hlen, size_t label_length, const uint8_t *label, size_t *length, uint8_t *message); The parameter hlen is the output length of the SHA function used for masking data: - SHA1_DIGEST_SIZE - SHA256_DIGEST_SIZE - SHA384_DIGEST_SIZE - SHA512_DIGEST_SIZE Is it possible to get feedback for this MR and eventually push it to the master branch? Thanks in advance /Nicolas

4 21

Support for ML-KEM (Kyber)
by Daiki Ueno 04 Mar '24

04 Mar '24

Hello, I created a draft patch to support ML-KEM (a post-quantum key encapsulation mechanism, formerly known as Kyber)[1], based on the explanation in the corresponding IETF draft[2]. There are probably a lot of rooms for improvements (performance, side-channel safety), but I'm sharing the code at: https://git.lysator.liu.se/nettle/nettle/-/merge_requests/62 Any comments or suggestions would be appreciated. Footnotes: [1] https://csrc.nist.gov/pubs/fips/203/ipd [2] https://datatracker.ietf.org/doc/draft-cfrg-schwabe-kyber/ Regards, -- Daiki Ueno

2 1

reply: reply: A new realization of ecc-sm2
by zhongxuan (A) 14 Feb '24

14 Feb '24

> "zhongxuan (A)" <zhongxuan2(a)huawei.com> writes: >> Where should I commit my patch? The access request to fork in Nettle / nettle * GitLab (liu.se)<https://git.lysator.liu.se/nettle/nettle> was denied. > Hi, I think you asked for "developer access" in the Nettle repo, which would allow you to push any changes you like to the repository. You can't have that, but unfortunately, I couldn't add any explanatory message when pushing the deny button in gitlab. > The usual way to contribute code in gitlab (as well as on github), is that you make your own "fork" of the repository, where you have full permissions. You commit your changes to a branch in that fork, and then create a merge request asking for changes to be merged into the original repo. Yes, I've tried to make a fork in https://git.lysator.liu.se/nettle/nettle/-/forks/new but failed, it just reports ' An error occurred while forking the project. Please try again. '. I replied a long email but tragically didn’t attach my patch. Here I attach my new patch of ecc-sm2. Besides, could you help me figure out what's wrong with my fork? I preferred to commit in fork mode, too. > See > https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html > on how to create a fork from the gitlab ui. > When you work with git locally, you can have both your own "fork" repo and the original repo as git "remotes". > And if gitlab doesn't work out for you, you could also send the updated patch to this list. > Best regards, > /Niels > -- > Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. > Internet email is subject to wholesale government surveillance.

2 1

Question on s390x AES acceleration
by Niels Möller 27 Jan '24

27 Jan '24

When I look at the logic in https://git.lysator.liu.se/nettle/nettle/-/blob/master/fat-s390x.c?ref_type…, automatic detection of hardware acceleration for aes128, aes192 and aes256 is done independently for each key size, based on corresponding bits in the "km status" words. While when configured manually, at configure time or using NETTLE_FAT_OVERRIDE, there are instead two flags, "msa_x1" enabling aes128 (and sha256), and "msa_x2" enabling aes192, aes256 (and sha512). I'm thinking that if we could enable all or none of the s390x aes assembly, then we could make things a bit simpler, only overriding the internal _nettle_aes_set_key and _nettle_aes_invert_key, instead of all 9 of aes{128,192,256}_{set_encrypt,set_decrypt,invert}_key. Are there s390x machines out there that have hardware support for just some of the aes key sizes but not all? Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

1 0

Sparc assembly
by Niels Möller 24 Jan '24

24 Jan '24

Hi, I just pushed changes to the ci script to enable sparc64 tests. It turned out to be rather easy with current debian-based tools, despite sparc64 no longer being a release architecture. (Install gcc-sparc64-linux-gnu cross compiler, use qemu-sparc64, only workaround (similar to some other archs) was that QEMU_LD_PREFIX had to be set explicitly). I don't now if anyone is interested in sparc performance, or contributing more sparc64 code (I'd consider this architecture rather obscure by now). But these tests should at least make it rather easy to maintain the code for the time being. Even as I consider some changes to the handling aes decryption subkeys that will require updates to this code. On the other hand, I'm considering deleting the sparc32 assembly code. Related machines like the sparc stations (I don't remember if I had a SS-5, SS-10 or SS-20 at the time I wrote this code, but I remember I had redhat linux installed on it rather than solaris) are out of support since the late 1990s. 64-bit sparcs, aka sparc v9, were introduced with the ultrasparc machines from 1995. Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

1 0

A new realization of ecc-sm2
by zhongxuan (A) 23 Jan '24

23 Jan '24

Hi Niels, I have sent a new version of ecc-sm2 realization patch cause that I'm not sure which git repository should I commit (gitlab or github?). I have tried the ecc_mod_inv and it works well in FP. Where should I commit my patch? The access request to fork in Nettle / nettle * GitLab (liu.se)<https://git.lysator.liu.se/nettle/nettle> was denied. Best regards

2 1

reply: reply: a realization of SM2 and questions about my subscription request of mailinglist
by zhongxuan (A) 22 Jan '24

22 Jan '24

Sorry for so long to reply, I tried to fork a branch in gitlab(https://git.lysator.liu.se/nettle/nettle) but failed, seemed that I don’t have enough permissions, or should I push my code in github(https://github.com/gnutls/nettle) ? Here are the replies: >"zhongxuan (A)" <zhongxuan2(a)huawei.com> writes: > >> Anyway, I made a realization of SM2, Here is the first part of it, >> including the curve and sm2_add and sm2_mul in affine coordinate. > >Thanks, I'm having a first read, see comments below. It would be good to have a link to the best english-language (and freely available) reference. I think you have told me earlier, and I've found https://datatracker.ietf.org/doc/html/draft-shen-sm2-ecdsa. It would be helpful with a reference in a comment, e.g., at the top of ecc-sm2.c. Insert a opensource link of this elliptic curve at the top of ecc-sm2.c > >> And if it's convenient to you, I can push the other parts including >> keygen, crypt and sign. > >I think it's a good first step to get basic scalar multiplication working, i.e., ecc_point_mul and ecc_point_mul_g working and tested. Thus this sm2 is also a 'a + 3 mod p = 0' elliptic curve, the mul_a and mul_g function of secp256r1 can also work. We have tested the result with the geometric method like what in eccdata.c. > >For signatures, are they similar to ECDSA, or something different? For encryption, how does that work? Yes its similar to ECDSA, you can refer to this page: https://datatracker.ietf.org/doc/html/draft-shen-sm2-ecdsa Or there is an official public manual about this curve: http://www.gmbz.org.cn/main/postDetail.html?id=20180724110812 I'm not sure whether could you access these pdfs. > >My initial comments on your patch inline below. > >Regards, >/Niels > >> --- /dev/null >> +++ b/ecc-sm2.c >> @@ -0,0 +1,261 @@ >> +/* ecc-sm2.c >> + >> + Compile time constant (but machine dependent) tables. > >Anything that is machine dependent should be in ecc-sm2.h, generated by eccdata. Removed. > >> + Copyright (c) Huawei Technologies Co., Ltd. 2022-2022. All rights reserved. >> + >> + This file is part of GNU Nettle. >> + >> + GNU Nettle is free software: you can redistribute it and/or >> + modify it under the terms of either: >> + >> + * the GNU Lesser General Public License as published by the Free >> + Software Foundation; either version 3 of the License, or (at your >> + option) any later version. >> + >> + or >> + >> + * the GNU General Public License as published by the Free >> + Software Foundation; either version 2 of the License, or (at your >> + option) any later version. >> + >> + or both in parallel, as here. >> + >> + GNU Nettle is distributed in the hope that it will be useful, >> + but WITHOUT ANY WARRANTY; without even the implied warranty of >> + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU >> + General Public License for more details. >> + >> + You should have received copies of the GNU General Public License and >> + the GNU Lesser General Public License along with this program. If >> + not, see http://www.gnu.org/licenses/. >> +*/ >> + >> +/* Development of Nettle's ECC support was funded by the .SE >> +Internet Fund. */ >> + >> +#if HAVE_CONFIG_H >> +# include "config.h" >> +#endif >> + >> +#include <string.h> >> +#include <assert.h> >> + >> +#include "sm2.h" >> +#include "sm2-internal.h" >> +#include "ecc-internal.h" >> +#include "ecc-sm2.h" >> +#include "ecc-curve.h" >> + >> +const char *nettle_sm2_a = >> +"fffffffeffffffffffffffffffffffffffffffff00000000fffffffffffffffc"; >> +const char *nettle_sm2_xG = >> +"32c4ae2c1f1981195f9904466a39c9948fe30bbff2660be1715a4589334c74c7"; >> +const char *nettle_sm2_yG = >> +"bc3736a2f4f6779c59bdcee36b692153d0a9877cc62a474002df32e52139f0a0"; > >These strings appear unused. Yep, this base point is unused, removed. The nettle_sm2_a used to check whether a point is in sm2 curve, by checking y^2 = x^3 + ax + b. > >> +static void >> +ecc_sm2_inv (const struct ecc_modulo *p, >> + mp_limb_t *rp, const mp_limb_t *ap, >> + mp_limb_t *scratch) { #define a5m1 scratch >> +#define >> +t0 (scratch + ECC_LIMB_SIZE) #define a15m1 t0 #define a32m1 a5m1 >> +#define a62m1 (scratch + 2*ECC_LIMB_SIZE) #define a96m1 t0 #define >> +a3 (scratch + 3*ECC_LIMB_SIZE) #define tp (scratch + >> +4*ECC_LIMB_SIZE) >> +/* >> + Addition chain for p - 2 = 2^{256} - 2^{224} + 2^{192} + 2^{96} - >> +3 >> + >> + 2^5 - 1 = 1 + 2 (2^4 - 1) = 1 + 2 (2^2+1)(2 + 1) 4 S + 3 M >> + 2^{15} - 1 = (2^5 - 1) (1 + 2^5 (1 + 2^5) 10 S + 2 M >> + 2^{16} - 1 = 1 + 2 (2^{15} - 1) S + M >> + 2^{32} - 1 = (2^{16} + 1) (2^{16} - 1) 16 S + M >> + >> + 2^{31} - 1 = (2^{16} - 1) * 2^{15} + 2^{15} - 1 >> + 2^{62} - 1 = (2^{31} - 1) * 2^{31} + 2^{31} - 1 >> + 2^{94} - 1 = (2^{62} - 1) * 2^{32} + 2^{32} - 1 >> + 2^{96} - 1 = (2^{94} - 1) * 2^{2} + 3 >> + >> + 2^{64} - 2^{32} - 1 = (2^{32} - 2) * 2^{32} + 2^{32} - 1 >> + 2^{160} - 2^{128} - 1 = (2^{64} - 2^{32} - 1) * 2^{96} + 2^{96} - 1 >> + 2^{254} - 2^{222} - 2^{94} + 2^{62} - 1 = (2^{160} - 2^{128} - 1) * 2^{94} + 2^{62} - 1 >> + 2^{256} - 2^{224} - 2^{96} + 2^{64} - 3 = (2^{254} - 2^{222} - >> + 2^{94} + 2^{62} - 1) * 2^{2} + 1 >> + >> + */ >> + ecc_mod_sqr (p, rp, ap, tp); /* a^2 */ >> + ecc_mod_mul (p, a3, rp, ap, tp); /* a^3 */ >> + ecc_mod_pow_2kp1 (p, t0, a3, 2, tp); /* a^{2^4 - 1} */ >> + ecc_mod_sqr (p, rp, t0, tp); /* a^{2^5 - 2} */ >> + ecc_mod_mul (p, a5m1, rp, ap, tp); /* a^{2^5 - 1}, a5m1 */ >> + >> + ecc_mod_pow_2kp1 (p, rp, a5m1, 5, tp); /* a^{2^{10} - 1, a5m1*/ >> + ecc_mod_pow_2k_mul (p, a15m1, rp, 5, a5m1, tp); /* a^{2^{15} - 1}, a5m1 a15m1 */ >> + ecc_mod_sqr (p, rp, a15m1, tp); /* a^{2^{16} - 2}, a15m1 */ >> + ecc_mod_mul (p, rp, rp, ap, tp); /* a^{2^{16} - 1}, a15m1 */ >> + ecc_mod_pow_2kp1 (p, a32m1, rp, 16, tp); /* a^{2^{32} - 1}, a15m1, a32m1 */ >> + ecc_mod_pow_2k_mul (p, rp, rp, 15, a15m1, tp); /* a^{2^{31} - 1}, >> + a15m1 */ >> + >> + ecc_mod_pow_2kp1 (p, a62m1, rp, 31, tp); /* a^{2^{62} - 1}, a62m1 >> + */ ecc_mod_pow_2k_mul (p, a96m1, a62m1, 32, a32m1, tp); /* >> + a^{2^{94} - 1}, a62m1, a32m1 */ ecc_mod_pow_2k_mul (p, a96m1, >> + a96m1, 2, a3, tp); /* a^{2^{96} - 1}, a96m1, a3 */ >> + >> + ecc_mod_sqr (p, rp, rp, tp); /* a^{2^{32} - 2} */ >> + ecc_mod_pow_2k_mul (p, rp, rp, 32, a32m1, tp); /* a^{2^{64} - >> +2^{32} - 1 */ >> + ecc_mod_pow_2k_mul (p, rp, rp, 96, a96m1, tp); /* a^{2^{160} - >> +2^{128} - 1 */ >> + ecc_mod_pow_2k_mul (p, rp, rp, 94, a62m1, tp); /* a^{2^{254} - >> +2^{222} - 2^{94} + 2^{62} - 1}, a62m1 */ >> + ecc_mod_pow_2k_mul (p, rp, rp, 2, ap, tp); /* a^{2^{256} - 2^{224} >> +- 2^{96} + 2^{64} - 3} */ } >> + >> +void >> +sm2_get_order (mpz_t order) >> +{ >> + if (!order->_mp_d) >> + return; >> + const struct ecc_curve *ecc = nettle_get_sm2(); >> + mpz_set_n(order, ecc->q.m, ecc->q.size); } > >Why is the sm2_get_order needed? It appears unused in the current patch. Yes, this is a test interface, removed. > >> +static mp_limb_t SM2_P[8] = { >> + 0xffffffff, 0xffffffff, 0x00000000, 0xffffffff, >> + 0xffffffff, 0xffffffff, 0xffffffff, 0xfffffffe, }; > >Is this for 32-bit limb size? On which platform have you tested the code? Should probably use _nettle_sm2.p.m instead. No, its still a 64-bit limb size, we use it in fast reduction, we will try to use a nettle interface instead. > >I'm a bit confused, because this looks like 32-bit limbs, but elsewhere you shift by 32 bits which isn't valid for this limb size. > >> +static int sm2_bn_cmp(const mp_limb_t *a, const mp_limb_t *b) { >> + int i; >> + for (i = 7; i >= 0; i--) { >> + if (a[i] > b[i]) >> + return 1; >> + if (a[i] < b[i]) >> + return -1; >> + } >> + return 0; >> +} > >This will not be side-channel silent. Seems that we can use mpn_cmp instead, though I don’t get the difference between mpn_cmp and this sm2_bn_cmp, is mpn_cmp also not side-channel silent? > >> +static void sm2_bn_sub(mp_limb_t *ret, const mp_limb_t *a, const >> +mp_limb_t *b) { >> + int i; >> + mp_limb_t r[8]; >> + r[0] = ((uint64_t)1 << 32) + a[0] - b[0]; >> + for (i = 1; i < 7; i++) { >> + r[i] = 0xffffffff + a[i] - b[i] + (r[i - 1] >> 32); >> + r[i - 1] &= 0xffffffff; >> + } >> + r[i] = a[i] - b[i] + (r[i - 1] >> 32) - 1; >> + r[i - 1] &= 0xffffffff; >> + memcpy(ret, r, 64); >> +} > >Is there some reason the general ecc_mod_sub can't work work? Seems that it can't work. We use a fast reduction matrix, splitting a 64 bits limb into two 32 bits limbs. I also tried mpn_sub_n but seems it doesn’t work too. I am trying to optimize the calculation or use ecc_mod here instead. > >> +static void >> +ecc_sm2_modp (const struct ecc_modulo *p, mp_limb_t *rp, mp_limb_t >> +*xp) { >> + uint64_t s[16] = {0}; >> + uint64_t d[8] = {0}; >> + uint64_t r[8] = {0}; >> + >> + for (int i = 0; i < 8; i++) { >> + s[2*i] = xp[i] & 0xffffffff; >> + s[2*i+1] = xp[i] >> 32; >> + } >> + >> + r[0] = s[0] + s[8] + s[9] + s[10] + s[11] + s[12] + ((s[13] + >> + s[14] >> + + s[15]) << 1); r[1] = s[1] + s[9] + s[10] + s[11] + s[12] + s[13] >> + + ((s[14] + s[15]) << 1); r[2] = s[2]; r[3] = s[3] + s[8] + s[11] >> + + s[12] + s[14] + s[15] + (s[13] << 1); r[4] = s[4] + s[9] + s[12] >> + + s[13] + s[15] + (s[14] << 1); r[5] = s[5] + s[10] + s[13] + >> + + s[14] (s[15] << 1); r[6] = s[6] + s[11] + s[14] + s[15]; r[7] = >> + + s[7] + >> + s[8] + s[9] + s[10] + s[11] + s[15] + ((s[12] + s[13] + s[14] + >> + s[15]) << 1); >> + >> + for (int i = 1; i < 8; i++) { >> + r[i] += r[i - 1] >> 32; >> + r[i - 1] &= 0xffffffff; >> + } >> + >> + d[2] = s[8] + s[9] + s[13] + s[14]; d[3] = d[2] >> 32; d[2] &= >> + 0xffffffff; sm2_bn_sub(r, r, d); >> + >> + while (sm2_bn_cmp(r, SM2_P) >= 0) { >> + sm2_bn_sub(r, r, SM2_P); >> + } >> + >> + rp[0] = (r[0] & 0xffffffff) + ((r[1] & 0xffffffff) << 32); rp[1] >> + = (r[2] & 0xffffffff) + ((r[3] & 0xffffffff) << 32); rp[2] = (r[4] >> + & 0xffffffff) + ((r[5] & 0xffffffff) << 32); rp[3] = (r[6] & >> + 0xffffffff) + ((r[7] & 0xffffffff) << 32); } > >I would suggest starting with the general ecc_mod function (I think it should work for the modulo used with sm2). When that is in place, one can add optimized variants for 32-bit and/or 64-bit limbs to speed that up. Here is a problem, ecc_mod stop in ' assert (bn < mn); ' in ecc-mod.c line 56, is sm2 different from other weierstrass curves or I made some mistakes? To avoid this I still use ecc_sm2_modp but change the cmp functions with mpn functions. > >> +const struct ecc_curve _nettle_sm2 = { >> + { >> + 256, >> + ECC_LIMB_SIZE, >> + ECC_BMODP_SIZE, >> + ECC_REDC_SIZE, >> + 4 * ECC_LIMB_SIZE, >> + 4 * ECC_LIMB_SIZE, >> + 0, >> + >> + ecc_p, >> + ecc_Bmodp, >> + ecc_Bmodp_shifted, >> + ecc_redc_ppm1, >> + ecc_pp1h, >> + >> + NULL, >> + ecc_sm2_modp, >> + ecc_sm2_inv, >> + NULL, >> + NULL, >> + }, >> + { >> + 256, >> + ECC_LIMB_SIZE, >> + ECC_BMODQ_SIZE, >> + 0, >> + ECC_MOD_INV_ITCH (ECC_LIMB_SIZE), >> + 0, >> + 0, >> + >> + ecc_q, >> + ecc_Bmodq, >> + ecc_Bmodq_shifted, >> + NULL, >> + ecc_qp1h, >> + >> + NULL, >> + NULL, >> + ecc_mod_inv, >> + NULL, >> + NULL, >> + }, >> + >> + ECC_REDC_SIZE == 0, >> + ECC_PIPPENGER_K, >> + ECC_PIPPENGER_C, >> + >> + ECC_ADD_JJA_ITCH (ECC_LIMB_SIZE), >> + ECC_ADD_JJJ_ITCH (ECC_LIMB_SIZE), >> + ECC_DUP_JJ_ITCH (ECC_LIMB_SIZE), >> + ECC_MUL_A_ITCH (ECC_LIMB_SIZE), >> + ECC_MUL_G_ITCH (ECC_LIMB_SIZE), >> + ECC_J_TO_A_ITCH(ECC_LIMB_SIZE, 4 * ECC_LIMB_SIZE), >> + >> + ecc_add_jja, >> + ecc_add_jjj, >> + ecc_dup_jj, > >I had expected pointers to new add and dup functions here, since existing functions assume a = -3. Thus this sm2's p = 2^256 - x^224 - 2^96 + 2^64 - 1, which is also a 'a + 3 mod p = 0' elliptic curve, the add_jja, add_jjj, dup_jj can also work. We proved it by comparing with geometric method. > >> + ecc_mul_a, >> + ecc_mul_g, >> + ecc_j_to_a, >> + >> + ecc_b, >> + ecc_unit, >> + ecc_table >> +}; >> + >> +const struct ecc_curve *nettle_get_sm2(void) { >> + return &_nettle_sm2; >> +} >> diff --git a/eccdata.c b/eccdata.c >> index 4d8827f..71a524d 100644 >> --- a/eccdata.c >> +++ b/eccdata.c >> @@ -44,6 +44,9 @@ >> >> /* Affine coordinates, for simplicity. Infinity point, i.e., te >> neutral group element, is represented using the is_zero flag. */ >> + >> +const char *nettle_sm2_a = >> +"fffffffeffffffffffffffffffffffffffffffff00000000fffffffffffffffc"; > >Do I get it right that sm2 uses a weierstrass curve, but with a different a value than the a = -3 used for the other weierstrass curves? >For the eccdata program, I would suggest adding the a constant to the struct ecc_curve, and use the same formulas for all the weierstrass curves. E.g, add an argument to ecc_curve_init_str to set a, and let NULL mean the default of -3. Now we add param a in eccdata first. Besides, I let NULL in EDWARDS curve, which means also -3 although EDWARDS don’t have a param a, would it be fine? Did some changes to ecc_dup to use same formulas in all weierstrass curves. > >> struct ecc_point >> { >> int is_zero; >> @@ -59,6 +62,8 @@ enum ecc_type >> ECC_TYPE_EDWARDS, >> /* -x^2 + y^2 = 1 - d x^2 y^2 */ >> ECC_TYPE_TWISTED_EDWARDS, >> + /* y^2 = x^3 + ax + b (mod p) */ >> + ECC_TYPE_SM2, >> }; >> >> struct ecc_curve >> @@ -145,64 +150,111 @@ static void >> ecc_dup (const struct ecc_curve *ecc, >> struct ecc_point *r, const struct ecc_point *p) { >> - if (ecc->type != ECC_TYPE_WEIERSTRASS) >> - { >> - ecc_add (ecc, r, p, p); >> - return; >> - } >> + if (ecc->type != ECC_TYPE_WEIERSTRASS && ecc->type != >> + ECC_TYPE_SM2) { >> + ecc_add (ecc, r, p, p); >> + return; >> + } >> if (ecc_zero_p (p)) >> ecc_set_zero (ecc, r); >> >> + else if (ecc->type == ECC_TYPE_SM2) { >> + mpz_t m, t, x, y, a; >> + >> + mpz_init (m); >> + mpz_init (t); >> + mpz_init (x); >> + mpz_init (y); >> + mpz_init_set_str(a, nettle_sm2_a, 16); >> + >> + /* m = (2 y)^-1 */ >> + mpz_mul_ui (m, p->y, 2); >> + mpz_invert (m, m, ecc->p); >> + >> + /* t = 3x^2 + a */ >> + mpz_mul (t, p->x, p->x); >> + mpz_mod (t, t, ecc->p); >> + mpz_mul_ui (t, t, 3); >> + mpz_mod (t, t, ecc->p); >> + mpz_add(t, t, a); >> + mpz_mod (t, t, ecc->p); >> + >> + /* t = t * m */ >> + mpz_mul (t, t, m); >> + mpz_mod (t, t, ecc->p); >> + >> + /* x' = t^2 - 2 x */ >> + mpz_mul (x, t, t); >> + mpz_submul_ui (x, p->x, 2); >> + >> + mpz_mod (x, x, ecc->p); >> + >> + /* y' = (x - x') * t - y */ >> + mpz_sub (y, p->x, x); >> + mpz_mul (y, y, t); >> + mpz_sub (y, y, p->y); >> + mpz_mod (y, y, ecc->p); >> + >> + r->is_zero = 0; >> + mpz_swap (x, r->x); >> + mpz_swap (y, r->y); >> + >> + mpz_clear (m); >> + mpz_clear (t); >> + mpz_clear (x); >> + mpz_clear (y); >> + } >> else >> - { >> - mpz_t m, t, x, y; >> - >> - mpz_init (m); >> - mpz_init (t); >> - mpz_init (x); >> - mpz_init (y); >> - >> - /* m = (2 y)^-1 */ >> - mpz_mul_ui (m, p->y, 2); >> - mpz_invert (m, m, ecc->p); >> - >> - /* t = 3 (x^2 - 1) * m */ >> - mpz_mul (t, p->x, p->x); >> - mpz_mod (t, t, ecc->p); >> - mpz_sub_ui (t, t, 1); >> - mpz_mul_ui (t, t, 3); >> - >> - mpz_mul (t, t, m); >> - mpz_mod (t, t, ecc->p); >> - >> - /* x' = t^2 - 2 x */ >> - mpz_mul (x, t, t); >> - mpz_submul_ui (x, p->x, 2); >> - >> - mpz_mod (x, x, ecc->p); >> - >> - /* y' = (x - x') * t - y */ >> - mpz_sub (y, p->x, x); >> - mpz_mul (y, y, t); >> - mpz_sub (y, y, p->y); >> - mpz_mod (y, y, ecc->p); >> - >> - r->is_zero = 0; >> - mpz_swap (x, r->x); >> - mpz_swap (y, r->y); >> - >> - mpz_clear (m); >> - mpz_clear (t); >> - mpz_clear (x); >> - mpz_clear (y); >> - } >> + { >> + mpz_t m, t, x, y; >> + >> + mpz_init (m); >> + mpz_init (t); >> + mpz_init (x); >> + mpz_init (y); >> + >> + /* m = (2 y)^-1 */ >> + mpz_mul_ui (m, p->y, 2); >> + mpz_invert (m, m, ecc->p); >> + >> + /* t = 3 (x^2 - 1) * m */ >> + mpz_mul (t, p->x, p->x); >> + mpz_mod (t, t, ecc->p); >> + mpz_sub_ui (t, t, 1); >> + mpz_mul_ui (t, t, 3); >> + >> + mpz_mul (t, t, m); >> + mpz_mod (t, t, ecc->p); >> + >> + /* x' = t^2 - 2 x */ >> + mpz_mul (x, t, t); >> + mpz_submul_ui (x, p->x, 2); >> + >> + mpz_mod (x, x, ecc->p); >> + >> + /* y' = (x - x') * t - y */ >> + mpz_sub (y, p->x, x); >> + mpz_mul (y, y, t); >> + mpz_sub (y, y, p->y); >> + mpz_mod (y, y, ecc->p); >> + >> + r->is_zero = 0; >> + mpz_swap (x, r->x); >> + mpz_swap (y, r->y); >> + >> + mpz_clear (m); >> + mpz_clear (t); >> + mpz_clear (x); >> + mpz_clear (y); >> + } >> } >> >> static void >> ecc_add (const struct ecc_curve *ecc, struct ecc_point *r, >> const struct ecc_point *p, const struct ecc_point *q) { >> - if (ecc->type == ECC_TYPE_WEIERSTRASS) >> + if (ecc->type == ECC_TYPE_WEIERSTRASS || ecc->type == >> + ECC_TYPE_SM2) >> { >> if (ecc_zero_p (p)) >> ecc_set (r, q); >> @@ -760,6 +812,25 @@ ecc_curve_init (struct ecc_curve *ecc, const char *curve) >> "c0d8f97ea1ca9472b5d444285d0d4f5b" >> "32e236f86de51839"); >> } >> + else if (!strcmp (curve, "sm2")) >> + { >> + ecc_curve_init_str (ecc, ECC_TYPE_SM2, >> + /* p */ >> + "fffffffeffffffffffffffffffffffff" >> + "ffffffff00000000ffffffffffffffff", >> + /* b */ >> + "28e9fa9e9d9f5e344d5a9e4bcf6509a7" >> + "f39789f515ab8f92ddbcbd414d940e93", >> + /* q (order) */ >> + "fffffffeffffffffffffffffffffffff" >> + "7203df6b21c6052b53bbf40939d54123", >> + /* g_x */ >> + "32c4ae2c1f1981195f9904466a39c994" >> + "8fe30bbff2660be1715a4589334c74c7", >> + /* g_y */ >> + "bc3736a2f4f6779c59bdcee36b692153" >> + "d0a9877cc62a474002df32e52139f0a0"); >> + } >> else >> { >> fprintf (stderr, "No known curve with name %s\n", curve); diff >> --git a/sm2-add.c b/sm2-add.c new file mode 100644 index >> 0000000..f32676c >> --- /dev/null >> +++ b/sm2-add.c >> @@ -0,0 +1,67 @@ >> +/* sm2-mul.c >> + >> + Copyright (c) Huawei Technologies Co., Ltd. 2022-2022. All rights reserved. >> + >> + This file is part of GNU Nettle. >> + >> + GNU Nettle is free software: you can redistribute it and/or >> + modify it under the terms of either: >> + >> + * the GNU Lesser General Public License as published by the Free >> + Software Foundation; either version 3 of the License, or (at your >> + option) any later version. >> + >> + or >> + >> + * the GNU General Public License as published by the Free >> + Software Foundation; either version 2 of the License, or (at your >> + option) any later version. >> + >> + or both in parallel, as here. >> + >> + GNU Nettle is distributed in the hope that it will be useful, >> + but WITHOUT ANY WARRANTY; without even the implied warranty of >> + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU >> + General Public License for more details. >> + >> + You should have received copies of the GNU General Public License and >> + the GNU Lesser General Public License along with this program. If >> + not, see http://www.gnu.org/licenses/. >> +*/ >> + >> +#if HAVE_CONFIG_H >> +# include "config.h" >> +#endif >> + >> +#include <string.h> >> + >> +#include "ecc.h" >> +#include "ecc-internal.h" >> + >> +#include "sm2.h" >> +#include "sm2-internal.h" >> + >> +int >> +sm2_add (struct ecc_point *r, const struct ecc_point *p, >> + const struct ecc_point *q) > >What's the usecase for this function? If it is needed, it might be better with a general ecc_point_add. Its just an encapsulation, we will remove it. > >> +{ >> + const struct ecc_curve *ecc = p->ecc; >> + if (!sm2_check_point(p) || !sm2_check_point(q)) { >> + return 0; >> + } >> + >> + mp_size_t itch = 3*SM2_LIMB_SIZE + ecc->mul_itch; mp_limb_t >> + *scratch = gmp_alloc_limbs (itch); mp_limb_t *pj = xalloc_limbs >> + (3*ecc->p.size); mp_limb_t *qj = xalloc_limbs (3*ecc->p.size); >> + ecc_a_to_j (ecc, pj, p->p); ecc_a_to_j (ecc, qj, q->p); >> + >> + ecc->add_hhh(p->ecc, scratch, pj, qj, scratch + 3*SM2_LIMB_SIZE); >> + ecc->h_to_a (ecc, 0, r->p, scratch, scratch + 3*SM2_LIMB_SIZE); >> + >> + gmp_free_limbs (scratch, itch); >> + free(pj); >> + free(qj); >> + return 1; >> +} >> diff --git a/sm2-internal.h b/sm2-internal.h new file mode 100644 >> index 0000000..adcc379 >> --- /dev/null >> +++ b/sm2-internal.h >> @@ -0,0 +1,69 @@ >> +/* sm2-internal.h >> + >> + Things that are used only by the testsuite and benchmark, and >> + not included in the library. > >Is that right? The file is included by library files, e.g., ecc-sm2.c. That’s not accurate, removed this. > >> + Copyright (c) Huawei Technologies Co., Ltd. 2022-2022. All rights reserved. >> + >> + This file is part of GNU Nettle. >> + >> + GNU Nettle is free software: you can redistribute it and/or >> + modify it under the terms of either: >> + >> + * the GNU Lesser General Public License as published by the Free >> + Software Foundation; either version 3 of the License, or (at your >> + option) any later version. >> + >> + or >> + >> + * the GNU General Public License as published by the Free >> + Software Foundation; either version 2 of the License, or (at your >> + option) any later version. >> + >> + or both in parallel, as here. >> + >> + GNU Nettle is distributed in the hope that it will be useful, >> + but WITHOUT ANY WARRANTY; without even the implied warranty of >> + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU >> + General Public License for more details. >> + >> + You should have received copies of the GNU General Public License and >> + the GNU Lesser General Public License along with this program. If >> + not, see http://www.gnu.org/licenses/. >> +*/ >> + >> +#ifndef SM2_INTERNAL_H_INCLUDED >> +#define SM2_INTERNAL_H_INCLUDED >> + >> +#include <assert.h> >> + >> +#include "nettle-meta.h" >> + >> +#include "sm2.h" >> + >> +#ifdef __cplusplus >> +extern "C" { >> +#endif >> + >> +#define xalloc nettle_xalloc >> +#define xalloc_limbs nettle_xalloc_limbs >> + >> +#define SM2_LIMB_SIZE 4 >> +#define SM2_LIMB_BYTES 8 >> + >> +#define IS_ILLEG_KEY(key) \ >> + (!(key)) || (((key)->ecc) != &_nettle_sm2) || !((key)->p) >> + >> +extern const char *nettle_sm2_a; >> +extern const char *nettle_sm2_xG; >> +extern const char *nettle_sm2_yG; >> + >> +void *xalloc(size_t size); >> + >> +mp_limb_t *xalloc_limbs(mp_size_t n); > >Much of this looks questionable to me. SM2_LIMB_BYTES and SM2_LIMB_SIZE are machine dependent. Using corresponding elements of struct ecc_curve would be better than the nettle_sm2_a, nettle_sm2_xG and nettle_sm2_yG strings. (If there's no good place in the current struct ecc_curve to store the a constant, that should be added). Yep, this should be changed. ALL macros machine dependent moved, I tried add para a in ecc_curve. Here is a problem, in the point check of ecc_point_set and test_ecc_point_valid_p > >And xalloc functions are already defined for the testsuite and benchmark. Removed. > >> + >> +#ifdef __cplusplus >> +} >> +#endif >> + >> +#endif /* NETTLE_INTERNAL_H_INCLUDED */ >> diff --git a/sm2-lib.c b/sm2-lib.c >> new file mode 100644 >> index 0000000..0fefb20 >> --- /dev/null >> +++ b/sm2-lib.c >> @@ -0,0 +1,63 @@ >> +/* sm2-lib.c >> + >> + Things that are used only by the testsuite and benchmark, and >> + not included in the library. > >I'd prefer to not have this file. In particular, it's confusing with "lib" in the name when it's not part of the library. The description is not accurate, file removed. > >> + Copyright (c) Huawei Technologies Co., Ltd. 2022-2022. All rights reserved. >> + >> + This file is part of GNU Nettle. >> + >> + GNU Nettle is free software: you can redistribute it and/or >> + modify it under the terms of either: >> + >> + * the GNU Lesser General Public License as published by the Free >> + Software Foundation; either version 3 of the License, or (at your >> + option) any later version. >> + >> + or >> + >> + * the GNU General Public License as published by the Free >> + Software Foundation; either version 2 of the License, or (at your >> + option) any later version. >> + >> + or both in parallel, as here. >> + >> + GNU Nettle is distributed in the hope that it will be useful, >> + but WITHOUT ANY WARRANTY; without even the implied warranty of >> + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU >> + General Public License for more details. >> + >> + You should have received copies of the GNU General Public License and >> + the GNU Lesser General Public License along with this program. If >> + not, see http://www.gnu.org/licenses/. >> +*/ >> + >> +#if HAVE_CONFIG_H >> +# include "config.h" >> +#endif >> + >> +#include <assert.h> >> +#include <stdlib.h> >> +#include <stdio.h> >> +#include <string.h> >> + >> +#include "sm2-internal.h" >> +#include "ecc-internal.h" >> + >> +void * >> +xalloc(size_t size) >> +{ >> + void *p = malloc(size); >> + if (size && !p) { >> + fprintf(stderr, "Virtual memory exhausted.\n"); >> + abort(); >> + } >> + >> + return p; >> +} >> + >> +mp_limb_t * >> +xalloc_limbs (mp_size_t n) >> +{ >> + return xalloc (n * sizeof (mp_limb_t)); } >> diff --git a/sm2-mul.c b/sm2-mul.c >> new file mode 100644 >> index 0000000..f65d196 >> --- /dev/null >> +++ b/sm2-mul.c >> @@ -0,0 +1,64 @@ >> +/* sm2-mul.c >> + >> + Copyright (c) Huawei Technologies Co., Ltd. 2022-2022. All rights reserved. >> + >> + This file is part of GNU Nettle. >> + >> + GNU Nettle is free software: you can redistribute it and/or >> + modify it under the terms of either: >> + >> + * the GNU Lesser General Public License as published by the Free >> + Software Foundation; either version 3 of the License, or (at your >> + option) any later version. >> + >> + or >> + >> + * the GNU General Public License as published by the Free >> + Software Foundation; either version 2 of the License, or (at your >> + option) any later version. >> + >> + or both in parallel, as here. >> + >> + GNU Nettle is distributed in the hope that it will be useful, >> + but WITHOUT ANY WARRANTY; without even the implied warranty of >> + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU >> + General Public License for more details. >> + >> + You should have received copies of the GNU General Public License and >> + the GNU Lesser General Public License along with this program. If >> + not, see http://www.gnu.org/licenses/. >> +*/ >> + >> +#if HAVE_CONFIG_H >> +# include "config.h" >> +#endif >> + >> +#include <string.h> >> + >> +#include "ecc.h" >> +#include "ecc-internal.h" >> + >> +#include "sm2.h" >> +#include "sm2-internal.h" >> + >> +int >> +sm2_mul (struct ecc_point *q, const struct ecc_scalar *n, >> + const struct ecc_point *p) >> +{ >> + const struct ecc_curve *ecc = p->ecc; >> + if (!sm2_check_point(p)) { >> + return 0; >> + } >> + mp_size_t itch = 3*SM2_LIMB_SIZE + p->ecc->mul_itch; >> + mp_limb_t *scratch = gmp_alloc_limbs (itch); >> + >> + mp_limb_t *pj = xalloc_limbs (3*SM2_LIMB_SIZE); ecc_a_to_j >> + (p->ecc, pj, p->p); >> + >> + p->ecc->mul(p->ecc, scratch, n->p, pj, scratch + 3*SM2_LIMB_SIZE); >> + p->ecc->h_to_a (p->ecc, 0, q->p, scratch, scratch + >> + 3*SM2_LIMB_SIZE); >> + >> + gmp_free_limbs (scratch, itch); >> + free(pj); >> + return 1; >> +} > >I think the general ecc_point_mul (and other ecc_point_* functions) should be used also for sm2. The validation done by sm2_check_point should go in ecc_point_set (currently, handling various curves in that function is a bit messy handling, it would make sense to add a function pointer in ecc_curve for doing the point validation. These encapsulations are removed. Add an ecc_point_check function from ecc_point_set, I wonder is there necessary to add a function pointer in ecc_curve? > >> diff --git a/sm2-point.c b/sm2-point.c new file mode 100644 index >> 0000000..0146692 >> --- /dev/null >> +++ b/sm2-point.c >> @@ -0,0 +1,105 @@ >> +/* sm2-point.c >> + >> + Copyright (c) Huawei Technologies Co., Ltd. 2022-2022. All rights reserved. >> + >> + This file is part of GNU Nettle. >> + >> + GNU Nettle is free software: you can redistribute it and/or >> + modify it under the terms of either: >> + >> + * the GNU Lesser General Public License as published by the Free >> + Software Foundation; either version 3 of the License, or (at your >> + option) any later version. >> + >> + or >> + >> + * the GNU General Public License as published by the Free >> + Software Foundation; either version 2 of the License, or (at your >> + option) any later version. >> + >> + or both in parallel, as here. >> + >> + GNU Nettle is distributed in the hope that it will be useful, >> + but WITHOUT ANY WARRANTY; without even the implied warranty of >> + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU >> + General Public License for more details. >> + >> + You should have received copies of the GNU General Public License and >> + the GNU Lesser General Public License along with this program. If >> + not, see http://www.gnu.org/licenses/. >> +*/ >> + >> +#if HAVE_CONFIG_H >> +# include "config.h" >> +#endif >> + >> +#include <stdio.h> >> +#include <string.h> >> +#include <stdlib.h> >> + >> +#include "ecc.h" >> +#include "ecc-internal.h" >> + >> +#include "sm2.h" >> +#include "sm2-internal.h" >> + >> +int >> +sm2_check_point(const struct ecc_point *point) { >> + mpz_t t, x, y, a; >> + mpz_t lhs, rhs; >> + int res; >> + mp_size_t size; >> + >> + if (IS_ILLEG_KEY(point) != 0) >> + return 0; >> + >> + size = point->ecc->p.size; >> + >> + /* First check range */ >> + if (mpn_cmp (point->p, point->ecc->p.m, size) >= 0 >> + || mpn_cmp (point->p + size, point->ecc->p.m, size) >= 0) >> + return 0; >> + >> + mpz_init (lhs); >> + mpz_init (rhs); >> + >> + mpz_init_set_str(a, nettle_sm2_a, 16); mpz_roinit_n (x, point->p, >> + size); mpz_roinit_n (y, point->p + size, size); >> + >> + mpz_mul (lhs, y, y); >> + >> + /* Check y^2 = x^3 + ax + b */ >> + mpz_mul (rhs, x, x); >> + mpz_add (rhs, rhs, a); >> + mpz_mul (rhs, rhs, x); >> + mpz_add (rhs, rhs, mpz_roinit_n (t, point->ecc->b, size)); >> + >> + res = mpz_congruent_p (lhs, rhs, mpz_roinit_n (t, point->ecc->p.m, >> + size)); >> + >> + mpz_clear (lhs); >> + mpz_clear (rhs); >> + mpz_clear (a); >> + >> + return res; >> +} >> + >> +int >> +sm2_point_set (struct ecc_point *p, const mpz_t x, const mpz_t y) { >> + if (p == NULL || p->p == NULL || x == NULL || y == NULL) >> + return 0; >> + >> + p->ecc = &_nettle_sm2; >> + mp_size_t size = p->ecc->p.size; >> + >> + mpz_limbs_copy (p->p, x, size); >> + mpz_limbs_copy (p->p + size, y, size); >> + >> + if (!sm2_check_point(p)) { >> + return 0; >> + } >> + >> + return 1; >> +} >> diff --git a/sm2.h b/sm2.h >> new file mode 100644 >> index 0000000..1443b68 >> --- /dev/null >> +++ b/sm2.h >> @@ -0,0 +1,65 @@ >> +/* sm2.h >> + Copyright (c) Huawei Technologies Co., Ltd. 2022-2022. All rights reserved. >> + This file is part of GNU Nettle. >> + GNU Nettle is free software: you can redistribute it and/or >> + modify it under the terms of either: >> + * the GNU Lesser General Public License as published by the Free >> + Software Foundation; either version 3 of the License, or (at your >> + option) any later version. >> + or >> + * the GNU General Public License as published by the Free >> + Software Foundation; either version 2 of the License, or (at your >> + option) any later version. >> + or both in parallel, as here. >> + GNU Nettle is distributed in the hope that it will be useful, >> + but WITHOUT ANY WARRANTY; without even the implied warranty of >> + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU >> + General Public License for more details. >> + You should have received copies of the GNU General Public License and >> + the GNU Lesser General Public License along with this program. If >> + not, see http://www.gnu.org/licenses/. >> +*/ >> + >> +#ifndef NETTLE_SM2_H_INCLUDED >> +#define NETTLE_SM2_H_INCLUDED >> + >> +#include "nettle-types.h" >> +#include "nettle-meta.h" >> + >> +#include "ecc.h" >> + >> +#ifdef __cplusplus >> +extern "C" { >> +#endif >> + >> +#define sm2_get_order nettle_sm2_get_order #define sm2_check_point >> +nettle_sm2_check_point #define sm2_point_set nettle_sm2_point_set >> +#define sm2_add nettle_sm2_add #define sm2_mul nettle_sm2_mul >> + >> +void >> +sm2_get_order(mpz_t order); >> + >> +int >> +sm2_check_point(const struct ecc_point *point); >> + >> +int >> +sm2_point_set (struct ecc_point *p, const mpz_t x, const mpz_t y); >> + >> +int >> +sm2_add (struct ecc_point *r, const struct ecc_point *p, >> + const struct ecc_point *q); >> + >> +int >> +sm2_mul (struct ecc_point *q, const struct ecc_scalar *n, >> + const struct ecc_point *p); > >There are no curve-specific public functions like this for any of the other curves, so it would be nice if we could eliminate them and just use the ecc_point_* functions. Sure. > >> +const struct ecc_curve * _NETTLE_ATTRIBUTE_PURE >> +nettle_get_sm2(void); > >I think this declaration belongs in ecc_curve.h. Moved. > >> +#ifdef __cplusplus >> +} >> +#endif >> + >> +#endif /* NETTLE_SM2_H_INCLUDED */ >> + >> diff --git a/testsuite/Makefile.in b/testsuite/Makefile.in index >> c266282..6bda2b7 100644 >> --- a/testsuite/Makefile.in >> +++ b/testsuite/Makefile.in >> @@ -56,7 +56,8 @@ TS_HOGWEED_SOURCES = sexp-test.c sexp-format-test.c \ >> eddsa-compress-test.c eddsa-sign-test.c \ >> eddsa-verify-test.c ed25519-test.c ed448-test.c \ >> gostdsa-sign-test.c gostdsa-verify-test.c \ >> - gostdsa-keygen-test.c gostdsa-vko-test.c >> + gostdsa-keygen-test.c gostdsa-vko-test.c \ >> + sm2-base-test.c \ >> >> TS_SOURCES = $(TS_NETTLE_SOURCES) $(TS_HOGWEED_SOURCES) CXX_SOURCES >> = cxx-test.cxx diff --git a/testsuite/sm2-base-test.c >> b/testsuite/sm2-base-test.c new file mode 100644 index >> 0000000..be03970 >> --- /dev/null >> +++ b/testsuite/sm2-base-test.c >> @@ -0,0 +1,161 @@ >> +#include "testutils.h" >> + >> +char *order = >> +"fffffffeffffffffffffffffffffffff7203df6b21c6052b53bbf40939d54123"; > >If you add sm2 to the list ecc_curves in testutils.c, existing ecc tests will test sm2 as well. You will need to also update the test_ecc_point_valid_p function and the ecc_ref list in the same file. Already added, seemed the ecc_mod is not compatible with sm2, I'm trying to figured out. > >> +char *pkey = >> +"81a2088f008d0e28dd4add66041cf1050cbaf053ab48f4284eb701152be5c310"; >> +char *xG = >> +"8ffdbc04ac27f21a41c878e171294962150fa9b3dece424d41abfa869260bbf0"; >> +char *yG = >> +"a6648a20e162a7ac07597f199d722ff965cfdfab1744aed669565b11bcf15cfe"; >> +char *xR = >> +"3e5641b3e68eb47e6fae1271057e1ea0faedbb49df0d690722eaca6e45f5a76c"; >> +char *yR = >> +"d0b0bf0d16a1e4dbc814a6e7b53c07a84997660b7ed0fa0cdeb93bf12000cdf6"; >> + >> +char *Px = >> +"8070905f2cf1118ec1d41a0d07dd8dd4ac663bdbe4ad85df101d0baa875d4699"; >> +char *Py = >> +"5a947c2c3b2a4bf6113e4e609190209b64f672ddca99b6a7dbf55e2fbf7019a3"; >> +char *Qx = >> +"3dd60d9474b46d903f3daf7f532eb9e81a5ea97e2676dfca39493a218a223feb"; >> +char *Qy = >> +"dd8fe0b3cf91c793d1df27a30f707d5d46b170478e210de110f6954749b40994"; >> +char *Rx = >> +"df86af4b5b7830ac4d6730e93bc3a4dd67e303c3e2824eb76dc61b26e2884f7f"; >> +char *Ry = >> +"23d8e385c6f7aea20d38df11de924427b3cea394e648e4b19b4ba086addc490a"; >> + >> +char *gx = >> +"32C4AE2C1F1981195F9904466A39C9948FE30BBFF2660BE1715A4589334C74C7"; >> +char *gy = >> +"BC3736A2F4F6779C59BDCEE36B692153D0A9877CC62A474002DF32E52139F0A0"; >> + >> +void sm2_point_print (struct ecc_point *p); void test_get_order >> +(void); void test_add (void); void test_mul (void); >> + >> +void >> +sm2_point_print (struct ecc_point *p) { >> + char str[1024]; >> + mpz_t x, y; >> + mpz_init (x); >> + mpz_init (y); >> + ecc_point_get(p, x, y); >> + mpz_get_str(str, 16, x); >> + printf("Px : %s\n", str); >> + mpz_get_str(str, 16, y); >> + printf("Py : %s\n", str); >> + mpz_clear(x); >> + mpz_clear(y); >> +} >> + >> +void >> +test_get_order (void) >> +{ >> + int ret = 0; >> + mpz_t r, R; >> + >> + mpz_init(r); >> + mpz_init_set_str(R, order, 16); >> + >> + sm2_get_order(r); >> + >> + ret = mpz_cmp(r, R); >> + ASSERT(ret == 0); >> + >> + mpz_clear(r); >> + mpz_clear(R); >> +} >> + >> +void >> +test_get_order_NULL (void) >> +{ >> + mpz_t r; >> + >> + mpz_init(r); >> + >> + r->_mp_d = NULL; >> + sm2_get_order(r); >> + >> + mpz_clear(r); >> +} >> + >> +void >> +test_add (void) >> +{ >> + int ret = 0; >> + const struct ecc_curve *ecc = nettle_get_sm2(); >> + struct ecc_point pointp, pointq, Res; >> + mpz_t x, y; >> + >> + ecc_point_init (&pointp, ecc); >> + ecc_point_init (&pointq, ecc); >> + ecc_point_init (&Res, ecc); >> + mpz_init (x); >> + mpz_init (y); >> + mpz_set_str(x, Px, 16); >> + mpz_set_str(y, Py, 16); >> + sm2_point_set(&pointp, x, y); >> + mpz_set_str(x, Qx, 16); >> + mpz_set_str(y, Qy, 16); >> + sm2_point_set(&pointq, x, y); >> + >> + sm2_add(&Res, &pointp, &pointq); >> + >> + if (verbose) >> + sm2_point_print (&Res); >> + >> + mpz_set_str(x, Rx, 16); >> + mpz_set_str(y, Ry, 16); >> + sm2_point_set(&pointq, x, y); >> + >> + ret = mpn_cmp(Res.p, pointq.p, SM2_LIMB_BYTES); ASSERT(ret == 0); >> + >> + ecc_point_clear(&pointp); >> + ecc_point_clear(&pointq); >> + ecc_point_clear(&Res); >> + mpz_clear (x); >> + mpz_clear (y); >> +} >> + >> +void >> +test_mul (void) >> +{ >> + int ret = 0; >> + const struct ecc_curve *ecc = nettle_get_sm2(); >> + struct ecc_point pub, pr, Res; >> + struct ecc_scalar key; >> + mpz_t x, y; >> + >> + ecc_point_init (&pub, ecc); >> + ecc_point_init (&pr, ecc); >> + ecc_point_init (&Res, ecc); >> + ecc_scalar_init (&key, ecc); >> + mpz_init (x); >> + mpz_init (y); >> + >> + mpz_set_str(x, pkey, 16); >> + ecc_scalar_set(&key, x); >> + mpz_set_str(x, xG, 16); >> + mpz_set_str(y, yG, 16); >> + sm2_point_set(&pub, x, y); >> + >> + sm2_mul(&pr, &key, &pub); >> + >> + if (verbose) >> + sm2_point_print (&pr); >> + >> + mpz_set_str(x, xR, 16); >> + mpz_set_str(y, yR, 16); >> + sm2_point_set(&Res, x, y); >> + >> + ret = mpn_cmp(Res.p, pr.p, SM2_LIMB_BYTES); ASSERT(ret == 0); >> + >> + ecc_point_clear(&pub); >> + ecc_point_clear(&pr); >> + ecc_point_clear(&Res); >> + ecc_scalar_clear(&key); >> + mpz_clear (x); >> + mpz_clear (y); >> +} >> + >> +void >> +test_main (void) >> +{ >> + test_get_order(); >> + test_get_order_NULL(); >> + test_add(); >> + test_mul(); >> +} >> diff --git a/testsuite/testutils.h b/testsuite/testutils.h index >> 3e23978..c2cf5e1 100644 >> --- a/testsuite/testutils.h >> +++ b/testsuite/testutils.h >> @@ -22,6 +22,8 @@ >> # include "ecc.h" >> # include "ecc-internal.h" >> # include "ecdsa.h" >> +# include "sm2.h" >> +# include "sm2-internal.h" >> # include "gmp-glue.h" >> # if NETTLE_USE_MINI_GMP >> # include "knuth-lfib.h" > >-- >Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. >Internet email is subject to wholesale government surveillance. > >

1 0

Re: ppc64: v2, AES/GCM Performance improvement with stitched implementation
by Danny Tsen 15 Jan '24

15 Jan '24

Hi Niels, Here is the version 2 for AES/GCM stitched patch. The stitched code is in all assembly and m4 macros are used. The overall performance improved around ~110% and 120% for encrypt and decrypt respectably. Please see the attached patch and aes benchmark. Thanks. -Danny > On Nov 22, 2023, at 2:27 AM, Niels Möller <nisse(a)lysator.liu.se> wrote: > > Danny Tsen <dtsen(a)us.ibm.com> writes: > >> Interleaving at the instructions level may be a good option but due to >> PPC instruction pipeline this may need to have sufficient >> registers/vectors. Use same vectors to change contents in successive >> instructions may require more cycles. In that case, more >> vectors/scalar will get involved and all vectors assignment may have >> to change. That’s the reason I avoided in this case. > > To investigate the potential, I would suggest some experiments with > software pipelining. > > Write a loop to do 4 blocks of ctr-aes128 at a time, fully unrolling the > round loop. I think that should be 44 instructions of aes mangling, plus > instructions to setup the counter input, and do the final xor and > endianness things with the message. Arrange so that it loads the AES > state in a set of registers we can call A, operating in-place on these > registers. But at the end, arrange the XORing so that the final > cryptotext is located in a different set of registers, B. > > Then, write the instructions to do ghash using the B registers as input, > I think that should be about 20-25 instructions. Interleave those as > well as possible with the AES instructions (say, two aes instructions, > one ghash instruction, etc). > > Software pipelining means that each iteration of the loop does aes-ctr > on four blocks, + ghash on the output for the four *previous* blocks (so > one needs extra code outside of the loop to deal with first and last 4 > blocks). Decrypt processing should be simpler. > > Then you can benchmark that loop in isolation. It doesn't need to be the > complete function, the handling of first and last blocks can be omitted, > and it doesn't even have to be completely correct, as long as it's the > right instruction mix and the right data dependencies. The benchmark > should give a good idea for the potential speedup, if any, from > instruction-level interleaving. > > I would hope 4-way is doable with available vector registers (and this > inner loop should be less than 100 instructions, so not too > unmanageable). Going up to 8-way (like the current AES code) would also > be interesting, but as you say, you might have a shortage of registers. > If you have to copy state between registers and memory in each iteration > of an 8-way loop (which it looks like you also have to do in your > current patch), that overhead cost may outweight the gains you have from > more independence in the AES rounds. > > Regards, > /Niels > > -- > Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. > Internet email is subject to wholesale government surveillance.

2 6

Re: Deleting obsolete assembly files?
by Niels Möller 08 Dec '23

08 Dec '23

nisse(a)lysator.liu.se (Niels Möller) writes: > Simon Josefsson <simon(a)josefsson.org> writes: > >> Also, remember that Niels proposal is not about removing these >> algorithms, just dropping the assembler variant. So they will continue >> to work fine on these platforms, but will take advantage of more code >> scrutiny. I think that is a reasonable trade-off. > And the only architectures that currently have any md5 assembly is x86 > and x86_64. On my x86_64 laptop, I see a rather modest performance gain > of about 6% over the C version. I don't expect anyone willing to work on > improved md5 performance, on x86_64 or on additional platforms. Getting back to this thread. I've pushed a change to delete md5 assembly on branch delete-md5-asm, for testing. I don't think carrying md5 assembly code is worth the complexity. The arcfour assembly was deleted in the 3.9 release. Deletion candidates remaining: 32-bit x86 (aes (non-aesni), sha1, camellia). 32-bit sparc. 32-bit ARM prior to ARMv6. Possibly also 64-bit sparc; currently, only sparc64-assembly is for aes, written in 2007 based on the sparc32 code. So unclear how relevant it is for current sparc processors). Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

1 0

Re: [PATCH] Add DRBG-CTR-AES256.
by Niels Möller 06 Dec '23

06 Dec '23

Simon Josefsson <simon(a)josefsson.org> writes: > Please release 3.9 before looking at this! :-) > > This adds DRBG-CTR-AES256, what do you think? I've merged this onto a branch add-drbg-ctr-aes256. I've made some additional changes: use union nettle_block16 where that made sense, rename Key -> key, fixed typo in testsite/Makefile, and extracted the output logic to its own helper function. It could be optimized to call aes256_encrypt with more than one block at a time, when possible, but probably not worth the extra complexity. Please have a look. For your sntrup761 patch that depends on this, will you be doing any more work on that in the near future? In the meantime, I've reworked the testing for side-channel silence, so it should be rather straight-forward to add such tests for sntrup761. Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

1 0

Patch to detect on CPU capabilities on Apple Silicon
by Tim Kosse 05 Dec '23

05 Dec '23

Hi, after building Nettle natively for Apple devices running Apple Silicon, I noticed a drastic performance different between the native build, and an x86_64 build emulated via Apple's Rosetta. The latter, despite emulation, was over 10 times faster in some algorithms, e.g. AES-128-GCM. I found out that get_arm64_features did not at all detect the CPU capabilities on Apple devices. The attached patch fixes the issue for me, with it in place the CPU features are correctly detected. AES-128-GCM benchmark results: Native (pre-patch): 200MB/s Emulated: 3.2GB/s Native (patched): 5.2GB/s Regards, Tim Kosse

2 2

Re: Mailing list archive is not working
by Niels Möller 05 Dec '23

05 Dec '23

Justus Winter <justus(a)sequoia-pgp.org> writes: > https://lists.lysator.liu.se/mailman/hyperkitty/list/nettle-bugs@lists.lysa… > > shows zero mails this year. Not sure where to raise that, so I'm > raising this here. I've asked mail admins. It turned out that the integration between mailman and hyperkitty was overlooked when the system was upgraded to mailman3 one and a half year ago. And it seems you are the first(!) user reporting that it's broken. Thanks for reaching out. As of today, archives are finally receiving new mail, but unfortunately it seems traffic since the upgrade until now isn't archived anywhere near the list server. Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

1 0

Re: How to update OpenSSL benchmark glue?
by Amos Jeffries 05 Dec '23

05 Dec '23

On 4/12/23 09:05, Niels Möller wrote: > Simo Sorce writes: > >> Ah you do not need to pass any property for the default provider so you >> can pass "" or even NULL. > > Thanks, I now have the RSA code updated (on branch update-openssl-bench, > if anyone wants to see the details). Initialization is now > > ctx->pkey_ctx = EVP_PKEY_CTX_new_from_name (NULL, "RSA", ""); > if (!ctx->pkey_ctx) > die ("OpenSSL EVP_PKEY_CTX_new_from_name (\"RSA\") failed.\n"); FWIW, In Squid with OpenSSLv3 we use this: EVP_PKEY_CTX_new_id(EVP_PKEY_RSA, NULL) > if (EVP_PKEY_keygen_init (ctx->pkey_ctx) <= 0) > die ("OpenSSL EVP_PKEY_keygen_init failed.\n"); > if (EVP_PKEY_CTX_set_rsa_keygen_bits(ctx->pkey_ctx, size) <= 0) > die ("OpenSSL EVP_PKEY_CTX_set_rsa_keygen_bits failed.\n"); > BIGNUM *e = BN_new(); > BN_set_word(e, 65537); > EVP_PKEY_CTX_set1_rsa_keygen_pubexp (ctx->pkey_ctx, e); > EVP_PKEY_keygen (ctx->pkey_ctx, &ctx->key); > > However, when I run this under valgrind (to check the corresponding > cleanup code doesn't leak memory), I get an error: > > ==3016684== Conditional jump or move depends on uninitialised value(s) > ==3016684== at 0x4B0B824: EVP_PKEY_generate (in /usr/lib/x86_64-linux-gnu/libcrypto.so.3) > ==3016684== by 0x10F30A: bench_openssl_rsa_init (hogweed-benchmark.c:721) > ==3016684== by 0x10D7AE: bench_alg (hogweed-benchmark.c:153) > ==3016684== by 0x10D7AE: main (hogweed-benchmark.c:972) > ==3016684== > > I wonder if that my code missing some initialization, or if that's an > openssl problem? How was the "ctx" variable created and initialized? The new EVP_PKEY logic has a lot of "ctx_is_legacy" checks based on the ctx itself. So that matters now where it did not before. > It's also unclear to me when the e bignum above can be > deallocated, does EVP_PKEY_CTX_set1_rsa_keygen_pubexp imply a full copy > into the context? Quick reading of the source code indicates that yes the context used BN_dup() one way or another. > > Next is updating the ecdsa benchmarks, since, e.g., > EC_KEY_new_by_curve_name, generates deprecation warnings. > > Regards, > /Niels > HTH Amos

3 2

None
by None 08 Mar '22

08 Mar '22

Mr.louis coker Taylor Special adviser to Pre. Charles Taylor, Email:louistaylor4@netscape.net Dear Sir/Madam, REQUEST FOR AN URGENT CONFIDENTIAL BUSINESS RELATIONSHIP. After due deliberation with my Uncle , I have decided to forward to you this business proposal. We want a reliable person who could assist us to transfer the sum of Twenty Million Five Hundred Thousand United States Dollars ( $20,500,000 ) into his / her account . My proposal to you will be very surprising, as we have not had any Personal contact before. However, I sincerely seek your confidence in this Transaction, which I propose to you as a person of transparency, honesty and high caliber. Let me first start by introducing myself properly to you, my name is Mr.Louis Coker Taylor Special Assistant to President Charles Taylor, the Former President of Republic of Liberia. As you may want to know and to make you less curious, I got your address from adverts in the business directory that portrayed your establishment in good light. I apologize if I have infringed on your privacy. You may know that My Uncle President Charles Taylor is Presently facing serious, Opposition from the LURDS Army (Liberia United for the Restoration of Democracy), The security and safety of my uncle is not guaranteed following serious support given to the rebels.View these websites: http://www.cnn.com/2003/WORLD/africa/08/11/taylor.warcrimes/index.html http://www.cnn.com/2003/WORLD/africa/08/11/liberia.1300/index.html My Uncle is seriously scared of this development, he does not want to suffer the experience of our Former president, Sergeant Samuel Doe who died in the hands of Price Yomi Johnson Who brutally massacred Samuel Doe, this was as a result of support the rebel had from foreign countries at that time. Based on these developments, the various foreign banks Account of my Uncle is already being investigated and that of Switzerland has already been frozen. In view of this very unpleasant development, the sum of $20.5Million dollar has been Secretly moved to a private security vault for safekeeping. My Uncle Mr Charles Taylor is Presently in Nigeria for asylum, he has confided in me With this task of seeking a very reliable and honest person that Will receive this Fund into his/her account for the future Survival of him and his family since he cannot presently deposit Or transfer the fund on his name or that of his family members Name due to the present situation in our country. He may likely Face war -crime charges as declared by the United Nations in Respect of his alleged involvement in civil war in Sierra-Leone. This money arose from various compensation he received from the Companies that were involved in the sale of rubber, timber and Mining sale of diamonds. He has instructed me that whomever that comes to our assistance should be compensated with 20% commission While 5% should be set aside to defray any expenses incurred by both parties. The 75% will be for My Uncle Charles Taylor, as the Principal owner of the Fund. Part of his share will be invested in your country in any venture with your advice. Consequent upon your acceptance of this proposal, kindly confirm your interest by Email OR. Your indication by revert Telephone to me of your sincere and serious interest will enable me fax you the PROCEDURE FOR OPERATION If my line is busy, please keep trying you will surely get through. NOTE: In the event of your inability to handle this transaction please inform me so that I can look for another reliable person who can assist in this respect. It might surprise you why I choose you and trusted you for this transaction. Yes, I believe that good friends can be discovered and business like this can not be realised without trust. This is why I have decided to trust you for this transaction. you are further informed that every ones interest and security had been considered before you were contacted, so be rest assured and feel free to go into this transaction with us. But let Honesty and Trust be our watchword throughout this transaction and your prompt reply will be highly appreciated. Kind Regards, Mr.Louis Coker Taylor NB: Please send your response to louistaylor4(a)netscape.net --a2d885be-e2c6-47db-836b-6f88a47446d3--

1 0

x86_64 gcm
by nisse＠lysator.liu.se 23 Feb '22

23 Feb '22

Hi, I've written a first version of a gcm_hash for x86_64, using the pclmulqdq (carryless mul) instructions. With only a single block at a time, no interleaving, this gives to 4.3 GByte/s, 0.5 cycles per byte on my laptop, one pclmulqdq every second cycle. If we could sustain one mul instruction per cycle, by interleaving, we could perhaps increase performance by another factor of two. See below. Configure options and fat setup still missing. Regards, /Niels C x86_64/gcm-hash.asm ifelse(` Copyright (C) 2022 Niels Möller This file is part of GNU Nettle. GNU Nettle is free software: you can redistribute it and/or modify it under the terms of either: * the GNU Lesser General Public License as published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version. or * the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. or both in parallel, as here. GNU Nettle is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received copies of the GNU General Public License and the GNU Lesser General Public License along with this program. If not, see http://www.gnu.org/licenses/. ') C Common registers define(`KEY', `%rdi') define(`P', `%xmm0') define(`BSWAP', `%xmm1') define(`H', `%xmm2') define(`D', `%xmm3') define(`T', `%xmm4') C void gcm_init_key (union gcm_block *table) PROLOGUE(_nettle_gcm_init_key) define(`MASK', `%xmm5') movdqa .Lpolynomial(%rip), P movdqa .Lbswap(%rip), BSWAP movups 2048(KEY), H C Middle element pshufb BSWAP, H C Multiply by x mod P, which is a left shift. movdqa H, T psllq $1, T psrlq $63, H C 127 --> 64, 63 --> 0 pshufd $0xaa, H, MASK C 64 --> (96, 64, 32, 0) pslldq $8, H C 0 --> 64 por T, H pxor T, T psubd MASK, T C All-ones if bit 127 was set pand P, T pxor T, H movups H, (KEY) C Set D = x^{-64} H = {H0, H1} + P1 H0 pshufd $0x4e, H, D C Swap H0, H1 pclmullqhqdq P, H pxor H, D movups D, 16(KEY) ret undefine(`MASK') EPILOGUE(_nettle_gcm_init_key) C Use pclmulqdq, doing one 64x64 --> 127 bit carry-less multiplication, C with source operands being selected from the halves of two 128-bit registers. C Variants: C pclmullqlqdq low half of both src and destination C pclmulhqlqdq low half of src register, high half of dst register C pclmullqhqdq high half of src register, low half of dst register C pclmulhqhqdq high half of both src and destination C To do a single block, M0, M1, we need to compute C C R = M0 D1 + M1 H1 C F = M0 D0 + M1 H0 C C Corresponding to x^{-127} M H = R + x^{-64} F C C Split F as F = F1 + x^64 F0, then the final reduction is C C R + x^{-64} F = R + P1 F0 + x^{64} F0 + F1 C C In all, 5 pclmulqdq. If we we have enough registers to interleave two blocks, C final reduction is needed only once, so 9 pclmulqdq for two blocks, etc. C C We need one register each for D and H, one for P1, one each for accumulating F C and R. That uses 5 out of the 16 available xmm registers. If we interleave C blocks, we need additionan D ang H registers (for powers of the key) and the C additional message word, but we could perhaps interlave as many as 4, with two C registers left for temporaries. define(`X', `%rsi') define(`LENGTH', `%rdx') define(`DATA', `%rcx') define(`R', `%xmm5') define(`M', `%xmm6') define(`F', `%xmm7') C void gcm_hash (const struct gcm_key *key, union gcm_block *x, C size_t length, const uint8_t *data) PROLOGUE(_nettle_gcm_hash) movdqa .Lpolynomial(%rip), P movdqa .Lbswap(%rip), BSWAP movups (KEY), H movups 16(KEY), D movups (X), R pshufb BSWAP, R sub $16, LENGTH jc .Lfinal .Loop: movups (DATA), M pshufb BSWAP, M .Lblock: pxor M, R movdqa R, M movdqa R, F movdqa R, T pclmullqlqdq D, F C D0 * M0 pclmullqhqdq D, R C D1 * M0 pclmulhqlqdq H, T C H0 * M1 pclmulhqhqdq H, M C H1 * M1 pxor T, F pxor M, R pshufd $0x4e, F, T C Swap halves of F pxor T, R pclmullqhqdq P, F pxor F, R add $16, DATA sub $16, LENGTH jnc .Loop .Lfinal: add $16, LENGTH jnz .Lpartial pshufb BSWAP, R movups R, (X) ret .Lpartial: C Copy zero padded to stack mov %rsp, %r8 sub $16, %rsp pxor M, M movups M, (%rsp) .Lread_loop: movb (DATA), %al sub $1, %r8 movb %al, (%r8) add $1, DATA sub $1, LENGTH jnz .Lread_loop C Move into M register, jump into loop with LENGTH = 0 movups (%rsp), M add $16, %rsp jmp .Lblock EPILOGUE(_nettle_gcm_hash) RODATA C The GCM polynomial is x^{128} + x^7 + x^2 + x + 1, C but in bit-reversed representation, that is C P = x^{128}+ x^{127} + x^{126} + x^{121} + 1 C We will mainly use the middle part, C P1 = (P + a + x^{128}) / x^64 = x^{563} + x^{62} + x^{57} ALIGN(16) .Lpolynomial: .byte 1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0xC2 .Lbswap: .byte 15,14,13,12,11,10,9,8,7,6,5,4,3,2,1,0 -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

2 3

Poly1305 based on radix 2^44 for S390x and PowerPC
by Maamoun TK 23 Feb '22

23 Feb '22

POWER9 and Z14 have introduced ' vmsumudm' and 'vmslg' instructions respectively for full 64-bit vector multiplication. This note demonstrates implementing Poly1305 based on radix 2^44 for optimal architecture utilization. In radix B = 2^44 we have the state and key as follows H = B^2 H_2 + B H_1 + H_0 R = B^2 R_2 + B R_1 + R_0 Where degrees of H_2 and R_2 are 42 and 36 respectively whereas other coefficients are of degree 44 We have B^3 = 20 so we can pre-compute R_1' = 20 * R_1 and R_2' = 20 * R_2 Now to multiply H by R we can write R H = B^2(R_2 H_0 + R_1 H_1 + R_0 H_2) + B(R_1 H_0 + R_0 H_1 + R_2' H_2) \____________T2__________/ \____________T1__________/ + R_0 H_0 + R_2' H_1 + R_1' H_2 \____________T0___________/ T_0 < 2^88 + 2^85 + 2^91 = 2^93 T_1 < 2^88 + 2^88 + 2^83 = 2^90 T_2 < 2^80 + 2^88 + 2^86 = 2^90 This is a good place to combine the interleaved multiplication state products of next consecutive blocks (In this case we interleave four-block multiplications by per-computing powers of key R) which rises up the degree of product parts. T_0 < 2^93 + 3*2^93 = 2^96 T_1 < 2^90 + 3*2^91 = 2^94 T_2 < 2^90 + 3*2^90 = 2^93 Now let's reduce this product to 2^130 divided to 2^44, 2^44, 2^42 for each part. T_0 ------------> T_1 ---------------> T_2 -------------------> T_0 ---------------> T_1 (96-44) (94-44+1) (93-42+1+3) (55-44+1) This chain keeps the carry addition for the last part (2^44+2^12) less than 2^44+2^22. Note the carry from T_2 would be multiplied by 5 before adding it to T_0 While the sequential carry addition achieves decent performance speed on PowerPC arch, an interleaved carry handling would get more speed up for s390x so let's figure an interleaved variant of carry addition. *----------------------------------------------------------------------------------------------* | Phase 1 | Phase 2 | Phase 3 | |------------------------------|---------------------------------|-------------------------------| | T_1 ------------> T_2 | T_2 -----------------> T_0 | T_0 --------------> T_1 | | (94-44) | (93-42+1+3) | (55-44+1) | |------------------------------|---------------------------------|-------------------------------| | T_0 -------------> T_1 | T_1 --------------> T_2 | | | (96-44) | (52-44+1) | | *-----------------------------------------------------------------------------------------------* This variant implies 3 sequential phases rather than four. Moreover, the long carry path from T_2 -> T_0 would've executed in parallel with another carry path. Patches of implementation based on radix 2^44 for both architectures are submitted to nettle with fat build support. https://git.lysator.liu.se/nettle/nettle/-/merge_requests/39 https://git.lysator.liu.se/nettle/nettle/-/merge_requests/41 Benchmark the implementations on POWER9 and Z15 *---------------------------------------------------------------------------------------------* | Arch | Nettle patch (radix 2^44) | OpenSSL (radix 2^26) | |-------------------|--------------------------------------|-----------------------------------| | PowerPC | 0.972 cycles/byte | 1.453 cycles/byte | |-------------------|--------------------------------------|-----------------------------------| | IBMz | 0.840 cycles/byte | 0.936 cycles/byte | *---------------------------------------------------------------------------------------------* This note can also be applied on x86_64 arch with 'AVX512VL' and 'AVX512_IFMA' extension support by utilizing 'VPMADD52HUQ' and 'VPMADD52LUQ' instructions of full 52-bit multiplication. regards, Mamone

2 2

[PATCH v2 0/7] Introduce SM4 symmetric cipher algorithm
by Tianjia Zhang 21 Feb '22

21 Feb '22

SM4 is a block cipher standard published by the government of the People's Republic of China, and it was issued by the State Cryptography Administration on March 21, 2012. The standard is GM/T 0002-2012 "SM4 block cipher algorithm". SM4 algorithm is a symmetric cipher algorithm in ShangMi cryptosystems. The block length and key length are both 128 bits. Both the encryption algorithm and the key derivation algorithm use 32 rounds of non-linear iterative structure, and the S box is a fixed 8 bits. The RFC 8998 specification defines the usage of ShangMi algorithm suite in TLS 1.3, etc. According to the State Cryptography Administration of China, its security and efficiency are equivalent to AES-128. Reference specification: 1. http://www.gmbz.org.cn/upload/2018-04-04/1522788048733065051.pdf 2. http://gmbz.org.cn/main/viewfile/20180108015408199368.html 3. https://tools.ietf.org/id/draft-ribose-cfrg-sm4-10.html 4. https://datatracker.ietf.org/doc/html/rfc8998 --- v2 changes: - use separate set_key functions to avoid two copies of the subkeys. - unify encryption and decryption operations with one function. - use unsigned type instead of uint32_t for loop counter i. - use four variables instead of four5-element array. Tianjia Zhang (7): doc: Add Copyright of SM3 hash algorithm Introduce SM4 symmetric cipher algorithm testsuite: add test for SM4 symmetric algorithm nettle-benchmark: bench SM4 symmetric algorithm doc: documentation for SM4 cipher algorithm gcm: Add SM4 as the GCM underlying cipher doc: documentation for GCM using SM4 cipher Makefile.in | 2 + examples/nettle-benchmark.c | 2 + gcm-sm4-meta.c | 60 ++++++++++ gcm-sm4.c | 81 +++++++++++++ gcm.h | 25 +++- nettle-meta-aeads.c | 1 + nettle-meta-ciphers.c | 1 + nettle-meta.h | 3 + nettle.texinfo | 81 +++++++++++++ sm4-meta.c | 49 ++++++++ sm4.c | 223 +++++++++++++++++++++++++++++++++++ sm4.h | 69 +++++++++++ testsuite/.gitignore | 1 + testsuite/Makefile.in | 2 +- testsuite/gcm-test.c | 18 +++ testsuite/meta-aead-test.c | 1 + testsuite/meta-cipher-test.c | 3 +- testsuite/sm4-test.c | 19 +++ 18 files changed, 638 insertions(+), 3 deletions(-) create mode 100644 gcm-sm4-meta.c create mode 100644 gcm-sm4.c create mode 100644 sm4-meta.c create mode 100644 sm4.c create mode 100644 sm4.h create mode 100644 testsuite/sm4-test.c -- 2.34.1

1 7

[PATCH 0/7] Introduce SM4 symmetric cipher algorithm
by Tianjia Zhang 21 Feb '22

21 Feb '22

SM4 is a block cipher standard published by the government of the People's Republic of China, and it was issued by the State Cryptography Administration on March 21, 2012. The standard is GM/T 0002-2012 "SM4 block cipher algorithm". SM4 algorithm is a symmetric cipher algorithm in ShangMi cryptosystems. The block length and key length are both 128 bits. Both the encryption algorithm and the key derivation algorithm use 32 rounds of non-linear iterative structure, and the S box is a fixed 8 bits. The RFC 8998 specification defines the usage of ShangMi algorithm suite in TLS 1.3, etc. According to the State Cryptography Administration of China, its security and efficiency are equivalent to AES-128. Reference specification: 1. http://www.gmbz.org.cn/upload/2018-04-04/1522788048733065051.pdf 2. http://gmbz.org.cn/main/viewfile/20180108015408199368.html 3. https://tools.ietf.org/id/draft-ribose-cfrg-sm4-10.html 4. https://datatracker.ietf.org/doc/html/rfc8998 Tianjia Zhang (7): doc: Add Copyright of SM3 hash algorithm Introduce SM4 symmetric cipher algorithm testsuite: add test for SM4 symmetric algorithm nettle-benchmark: bench SM4 symmetric algorithm doc: documentation for SM4 cipher algorithm gcm: Add SM4 as the GCM underlying cipher doc: documentation for GCM using SM4 cipher Makefile.in | 2 + examples/nettle-benchmark.c | 2 + gcm-sm4-meta.c | 60 ++++++++++ gcm-sm4.c | 81 +++++++++++++ gcm.h | 25 +++- nettle-meta-aeads.c | 1 + nettle-meta-ciphers.c | 1 + nettle-meta.h | 3 + nettle.texinfo | 81 +++++++++++++ sm4-meta.c | 49 ++++++++ sm4.c | 225 +++++++++++++++++++++++++++++++++++ sm4.h | 71 +++++++++++ testsuite/.gitignore | 1 + testsuite/Makefile.in | 2 +- testsuite/gcm-test.c | 18 +++ testsuite/meta-aead-test.c | 1 + testsuite/meta-cipher-test.c | 3 +- testsuite/sm4-test.c | 19 +++ 18 files changed, 642 insertions(+), 3 deletions(-) create mode 100644 gcm-sm4-meta.c create mode 100644 gcm-sm4.c create mode 100644 sm4-meta.c create mode 100644 sm4.c create mode 100644 sm4.h create mode 100644 testsuite/sm4-test.c -- 2.32.0

2 9

Feature request: OCB mode
by Justus Winter 16 Feb '22

16 Feb '22

Hello, we (Sequoia PGP) would love to see OCB being implemented in Nettle. The OpenPGP working group is working on a revision of RFC4880, which will mostly be a cryptographic refresh, and will bring AEAD to OpenPGP. The previous -now abandoned- draft called for EAX being mandatory, and OCB being optional [0]. This was motivated by OCB being encumbered by patents. However, said patents were waived by the holder [1]. 0: https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-rfc4880bis-10#sect… 1: https://mailarchive.ietf.org/arch/msg/cfrg/qLTveWOdTJcLn4HP3ev-vrj05Vg/ With OCB being no longer patent-encumbered, it seems preferable over the two-pass EAX construction. Therefore, it seems plausible that the WG makes OCB mandatory to implement. To support that in Sequoia, we'd need support for that in Nettle (Nettle is our main cryptographic backend). Unfortunately, we don't have the expertise in our team to contribute a patch, and we currently aren't in a position to offer funding for the implementation. Thanks, Justus

2 5

Latency in polynomial evaluation
by nisse＠lysator.liu.se 07 Feb '22

07 Feb '22

Hi, I've been thinking a bit more on the structure of polynomial evaluation, which at a high level is rather similar for ghash and gcm. ** Intro ** The function to be computed is R_j = K (R_{j-1} + M_j) where K is the secret key and M_j are the message blocks. Operations take place in some finite field. With n message blocks, M_0, ..., M_{n-1}, and initial R_{-1} = 0, we get R_{n-1} = m_{n-1} K + m_{n-2} K^2 + ... m_0 K^n I.e., a degree n polynomial with coefficients M_j, constant term = 0, evaluated at the point K. To be concrete, consider a 64-bit architecture, and a finite field where elements are represented as two words (for poly1305, we need two words plus a few extra bits, but ignore that now, for simplicity. And for ghash, let's also ignore the complications from bit-reversal). Let B represent the bignum base. I'm going to make this a bit handwavy, but we'll have B = 2^64 or B = x^64 depending on type of field. The finite field is represented by a mod P operation, where the structure of P is nice, with a leading one bit followed by more than 64 zeros, and then a few more non-zero bits at the end. This implies that we can define a multiply operation Y_2 B^2 + Y_1 B + Y_0 = (X_1 B + X_0) (K_1 B + K_0) (mod P) by four independent independent multiplication instructions (widening, 64x64 --> 128) involving X and some precomputed values depending on K, and accumulation only involving shifts/adds that have low latency. The result is not fully reduced mod P; it consists of three words. We can then reduce this to two words by multiplying Y_2 by a suitable single-word constant, with final two-word result R = C Y_2 + Y_1 B + Y_0 Applying this to the original recurrency, R_j = K (R_{j-1} + M_j), the X input corresponds to R_{j-1} + M_j, so the critical dependency path from R_{j-1} to R_j includes *two* multiply latencies. E.g, if multiply latency is 5 cycles, it's not possible to get this evaluation scheme to run faster than 10 cycles per block. (In practice, the accumulation will also contribute one or a few cycles to the critical path, but *much* less than those two multiplies). So question is, how can we do better? ** Postponing reduction ** The approach taken in the new x86_64 poly1305 code I just pushed is to skip the final reduction, and let the state be one word larger (and this is particularly cheap for poly1305, because we don't quite increase state size by a word, but from two words + 3 bits to two words plus ~60 bits). The multiply operation becomes Y_2 B^2 + Y_1 B + Y_0 = (X_2 B^2 + X_1 B + X_0) (K_1 B + K_0) (mod P) This can be arranged with 6 independent multiply instructions + cheap accumulation. (I haven't worked out the details for the ghash case, but I do expect that it's rather practival there too). Then the dependency chain from one block to the next is reduced to one multiply latency, 5 cycles in our example. In case all other needed instructions can be scheduled (manually, or by the processor's out-of-order machinery) to run in 5 cycles in parallel with the multiplies, we would get a running time of 5 cycles per block. ** Interleaving ** The other approach, used in the recent powerpc gcm code, is to interleave multiple blocks. For simplicity, only consider 2-way interleaving here. The key thing is that if we expand te recurrency once, we get R_j = K (M_j + K (R_{j-2} + M_{j-1})) = K M_j + K^2 (R_{j-2} + M_{j-1}) We get two field multiplications, but one of them, K M_j, is completely independent of previous blocks (R_{j-2}), and can be computed in parallel. It may add a cycle or so to accumulation latency, but we can do essentially twice as much work without making the critical path longer. We get 8 independent multiply instructions, and one dependent for the final folding. Can be extended to more than two blocks if needed (depending on number of available registers). Another variant could be to separate even and odd parts of the polynomial being evaluated, and evaluate both parts at K^2. We can then compute the two recurrencies E_j = K^2 (E_{j-1} + M_{2j}) O_j = K^2 (O_{j-1} + M_{2j+1}) in parallel. It's unclear to me what the pros and cons are compared to previous variant. One may get some advantage from both multiplies using the same factor K^2. On the other hand, each recurrency has to be accumulated and folded separately, which costs instructions and registers. Maybe more useful for hardware implementation? This variant is currently not used in Nettle. ** Doing both ** It's possible to combine those two tricks. Processing of two blocks would then be an operation of the form Z_2 B^2 + Z_1 B + Z_0 = (X_2 B^2 + X_1 B + X_0) K^2 + (Y_1 B + Y_0) K Here, the Xs (three words) represent R_{j-2} + M_{j-1}, the Ys repreent M_{j-2}, and the Zs represents R_j, as three words (without final folding). We would need 10 independent multiples, one more than with plain interleaving, but critical path includes only one multiply latency. I think this is a promising alternative, if one would otherwise need to interleaving a large number of blocks to get full utilization of the multipliers. ** How to choose ** When implementing one of those schemes, different processor resources may be the bottleneck. I'd expect it to be one of o Multiply latency, i.e, latency of the dependency chain from one block to the next (including also a few additions, but multiply latency willb e the main part). If this is the bottleneck, it means all other instructions can be scheduled in parallel, and the processor will sit idle for some cycles, waiting for a multiply to complete. Typical latency for multiply is 5 times longer than for an addition (but ratio difers quite a bit between processors, of course) o Multiply throughput, i.e., the maximum number of (independent) multiply instructions that can be run per cycle. Typical number is 0.5 -- 2. If this is the bottleneck, the processor will spend some cycles idle, waiting for a multiplier to be ready to accept a new input. o A superscalar processor can issue several instructinos in the same cycle, but there's a fix small limit. Typical number is 2 -- 6. So, e.g., if the processor can issue maximum 4 instructions per cycle, the evaluation loop consists of 40 instructions, and the loop actually runs in close to 10 cycles per iteration, then instruction issue is the bottleneck. The tricks discussed in this note are useful for finding an evaluation scheme where multiply latency isn't a bottleneck. But once a loop hits the limit on multiply throughput or instructions per cycle, other tricks are needed to optimize further. In particular, the postponed reduction has a cost in multiply throughput, since it needs some additional multiply instruction. I think one should aim to hit the limit on multiply throughput; that one is hard to negotiate (it's possible to reduce the number of multiply instructions somewhat, by the Karatsuba trick, but due to the additional overhead, likely to be useful only on processors with particularly low multiply throughput). Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

2 3

[Arm64, PowerPC64, S390x] Optimize Poly1305
by Maamoun TK 28 Jan '22

28 Jan '22

I created merge requests that have improvements of Poly1305 for arm64, powerpc64, and s390x architectures by following using two-way interleaving. https://git.lysator.liu.se/nettle/nettle/-/merge_requests/38 https://git.lysator.liu.se/nettle/nettle/-/merge_requests/39 https://git.lysator.liu.se/nettle/nettle/-/merge_requests/41 The patches have 41.88% speedup for arm64, 142.95% speedup for powerpc64, and 382.65% speedup for s390x. OpenSSL is still ahead in terms of performance speed since it uses 4-way interleaving or maybe more!! Increasing the interleaving ways more than two has nothing to do with parallelism since the execution units are already saturated by using 2-ways for the three architectures. The reason behind the performance improvement is the number of execution times of reduction procedure is cutted by half for 4-way interleaving since the products of multiplying state parts by key can be combined before the reduction phase. Let me know if you are interested in doing that on nettle! It would be nice if the arm64 patch will be tested on big-endian mode since I don't have access to any big-endian variant for testing. regards, Mamone

3 15

[PATCH v2 0/6] Add powerpc64 assembly for elliptic curves
by Amitay Isaacs 24 Jan '22

24 Jan '22

Hi, This series of patches add the powerpc64 assembly for modp/redc functions for elliptic curves P192, P224, P256, P384, P521, X25519 and X448. It results in 15-30% performance improvements as measured on POWER9 system using hogweed-benchmark. I posted the modified codes in the earlier email thread, but I think posting them as a seperate series will make them easier to cherry pick. V2 changes: - Use actual register names when storing/restoring from stack - Drop m4 definitions which are not in use - Simplify C2 folding for P192 curve Amitay Isaacs (2): ecc: Add powerpc64 assembly for ecc_192_modp ecc: Add powerpc64 assembly for ecc_224_modp Martin Schwenke (4): ecc: Add powerpc64 assembly for ecc_384_modp ecc: Add powerpc64 assembly for ecc_521_modp ecc: Add powerpc64 assembly for ecc_25519_modp ecc: Add powerpc64 assembly for ecc_448_modp powerpc64/ecc-curve25519-modp.asm | 101 +++++++++++++ powerpc64/ecc-curve448-modp.asm | 174 +++++++++++++++++++++++ powerpc64/ecc-secp192r1-modp.asm | 87 ++++++++++++ powerpc64/ecc-secp224r1-modp.asm | 123 ++++++++++++++++ powerpc64/ecc-secp384r1-modp.asm | 227 ++++++++++++++++++++++++++++++ powerpc64/ecc-secp521r1-modp.asm | 166 ++++++++++++++++++++++ 6 files changed, 878 insertions(+) create mode 100644 powerpc64/ecc-curve25519-modp.asm create mode 100644 powerpc64/ecc-curve448-modp.asm create mode 100644 powerpc64/ecc-secp192r1-modp.asm create mode 100644 powerpc64/ecc-secp224r1-modp.asm create mode 100644 powerpc64/ecc-secp384r1-modp.asm create mode 100644 powerpc64/ecc-secp521r1-modp.asm -- 2.34.1

2 8

[PATCH 0/7] Add powerpc64 assembly for elliptic curves
by Amitay Isaacs 21 Jan '22

21 Jan '22

Hi, This series of patches add the powerpc64 assembly for modp/redc functions for elliptic curves P192, P224, P256, P384, P521, X25519 and X448. It results in 15-30% performance improvements as measured on POWER9 system using hogweed-benchmark. master ------ name size sign/ms verify/ms ecdsa 192 13.5465 3.8313 ecdsa 224 8.4079 2.5289 ecdsa 256 8.5772 2.4691 ecdsa 384 3.4361 0.9765 ecdsa 521 2.2918 0.6785 eddsa 255 15.0672 4.1138 eddsa 448 4.7115 1.3067 curve 255 15.5206 6.4745 curve 448 4.7906 2.0458 this series ----------- name size sign/ms verify/ms ecdsa 192 17.5450 5.6564 ecdsa 224 10.8847 3.7482 ecdsa 256 11.0208 3.5215 ecdsa 384 5.1133 1.6133 ecdsa 521 2.8815 0.9348 eddsa 255 17.4936 4.9027 eddsa 448 6.0401 1.7075 curve 255 18.1034 7.6884 curve 448 6.1756 2.7095 Amitay Isaacs (3): ecc: Add powerpc64 assembly for ecc_192_modp ecc: Add powerpc64 assembly for ecc_224_modp ecc: Add powerpc64 assembly for ecc_256_redc Martin Schwenke (4): ecc: Add powerpc64 assembly for ecc_384_modp ecc: Add powerpc64 assembly for ecc_521_modp ecc: Add powerpc64 assembly for ecc_25519_modp ecc: Add powerpc64 assembly for ecc_448_modp powerpc64/ecc-curve25519-modp.asm | 103 ++++++++++++++ powerpc64/ecc-curve448-modp.asm | 174 +++++++++++++++++++++++ powerpc64/ecc-secp192r1-modp.asm | 93 ++++++++++++ powerpc64/ecc-secp224r1-modp.asm | 123 ++++++++++++++++ powerpc64/ecc-secp256r1-redc.asm | 144 +++++++++++++++++++ powerpc64/ecc-secp384r1-modp.asm | 227 ++++++++++++++++++++++++++++++ powerpc64/ecc-secp521r1-modp.asm | 166 ++++++++++++++++++++++ 7 files changed, 1030 insertions(+) create mode 100644 powerpc64/ecc-curve25519-modp.asm create mode 100644 powerpc64/ecc-curve448-modp.asm create mode 100644 powerpc64/ecc-secp192r1-modp.asm create mode 100644 powerpc64/ecc-secp224r1-modp.asm create mode 100644 powerpc64/ecc-secp256r1-redc.asm create mode 100644 powerpc64/ecc-secp384r1-modp.asm create mode 100644 powerpc64/ecc-secp521r1-modp.asm -- 2.33.1

2 26

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

nettle-bugs