nettle-bugs

nettle-bugs@lists.lysator.liu.se

3 participants
2180 discussions

[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

[Arm64, S390x] Optimize Chacha20
by Maamoun TK 20 Jan '22

20 Jan '22

I created merge requests that have improvements of Chacha20 for arm64 and s390x architectures by following the approach used in powerpc implementation. https://git.lysator.liu.se/nettle/nettle/-/merge_requests/37 https://git.lysator.liu.se/nettle/nettle/-/merge_requests/40 The patches have 80.85% speedup for arm64 arch and 284.79% speedup for s390x arch. 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

2 5

[S390x] Optimize various elliptic curve functions
by Maamoun TK 19 Jan '22

19 Jan '22

I created merge requests that have improvements of prime modulo functions of elliptic curves and scalar multiply of curve25519 and curve448 for s390x architecture https://git.lysator.liu.se/nettle/nettle/-/merge_requests/42 https://git.lysator.liu.se/nettle/nettle/-/merge_requests/43 The prime modulo functions are implemented using basic arithmetic instructions (including addition with carry and subtraction with borrow) while scalar multiply of curve25519 and curve448 takes advantage of hardware-accelerated instruction pcc (Perform Cryptographic Computation). Benchmark numbers of the patches are attached to the MR description. regards, Mamone

1 0

Re: Build problem on ppc64be + musl
by Maamoun TK 04 Jan '22

04 Jan '22

On Wed, Aug 18, 2021 at 11:38 PM Stijn Tintel <stijn(a)linux-ipv6.be> wrote: > On 18/08/2021 22:29, Maamoun TK wrote: > > On Tue, Aug 17, 2021 at 9:40 AM Niels Möller <nisse(a)lysator.liu.se > > <mailto:nisse@lysator.liu.se>> wrote: > > > > The configuration where it didn't work was > > powerpc64-openwrt-linux-musl. I'd like Nettle to work on embedded > > systems whenever practical. But support depends on assistance from > > users > > of those systems. > > > > As I understood it, this system needs to use the v2 ABI. I would hope > > it's easy to detect the abi used by the configured C compiler, and > > then > > select the same prologue sequence as is currently used for > > little-endian. I.e., one more configure test, and changing the > > "ifelse(WORDS_BIGENDIAN,no," condition in powerpc64/machine.m4 to > > check > > a different configure variable. > > > > > > I skipped processing the assembly files with a different approach, I > > made the configuration check for musl and endianness variant to > > trigger assembly processing. You can check the fix in this branch > > https://git.lysator.liu.se/mamonet/nettle/-/tree/ppc64_musl_fix > > <https://git.lysator.liu.se/mamonet/nettle/-/tree/ppc64_musl_fix> > > Apparently, the bug reporter uses a cross-compiler for powerpc arch. > > It would be great to run this fix at the same bug environment since I > > tested the patch in different circumstances. > > Your patch has no effect in my environment (OpenWrt build system), as > host_os is linux-gnu, according to config.log, so it doesn't match > *musl. See [1] for config.log and [2] for full compile log. > > The output of powerpc64-openwrt-linux-musl-gcc -E -dM - </dev/null | > sort, which was requested earlier in this thread can be seen at [3]. > > Thanks, > Stijn > > [1] https://gist.github.com/9e0ecb025033dda1d0d58094da84c308 > [2] https://gist.github.com/stintel/0e7046df511cf4d1ca20edb56df50b1b > [3] https://gist.github.com/stintel/b3651a7db87edea9e8bd0aef242bcdae config.guess detects the C standard library based on a result from the compiler defined in "CC_FOR_BUILD" variable, for some reason OpenWrt build system failed to set that variable properly, from your config.log I can see CC_FOR_BUILD='gcc -O -g' but when I use bare musl tools I get CC_FOR_BUILD='musl-gcc' There is nothing specific in the output of powerpc64-openwrt-linux-musl-gcc -E -dM log as I can see. In musl libc FAQ, they stated that there is no __MUSL__ in the preprocessor macros https://wiki.musl-libc.org/faq.html regards, Mamone

2 9

Status update
by nisse＠lysator.liu.se 17 Dec '21

17 Dec '21

Hi, just a heads up that I'll likely not be very responsive next few weeks. I may or may not get some hacking time during Christmas holidays. What I'd like to do when I get time: Review recent patches for powerpc ecc and sm4. Complete support for ANSI x9.62 (I'm not really up-to-date on the details, but needed square root code is already in, and there's code to do the rest was posted by Wim Lewis long ago). Prepare a new release. Maybe write salsa20 and chacha assembly for more platforms. But not necessarily in that order. Feel free to reply with suggested priorities, and remind me if there's something important that I've missed. Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

1 0

[PATCH] doc: documentation fot SM3 hash
by Tianjia Zhang 07 Dec '21

07 Dec '21

Signed-off-by: Tianjia Zhang <tianjia.zhang(a)linux.alibaba.com> --- nettle.texinfo | 74 ++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 72 insertions(+), 2 deletions(-) diff --git a/nettle.texinfo b/nettle.texinfo index 39d01159..76934637 100644 --- a/nettle.texinfo +++ b/nettle.texinfo @@ -950,6 +950,52 @@ This function also resets the context in the same way as @code{streebog256_init}. @end deftypefun +@subsubsection @acronym{SM3} + +SM3 is a cryptographic hash function standard adopted by the government of the +People's Republic of China, which was issued by the Cryptography Standardization +Technical Committee of China on December 17, 2010. The corresponding standard +is GM/T 0004-2012 "SM3 Cryptographic Hash Algorithm". + +SM3 algorithm is a hash algorithm in ShangMi cryptosystems. SM3 is mainly used +for digital signature and verification, message authentication code generation +and verification, random number generation, and 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 SHA-256. + +Nettle defines SM3 in @file{<nettle/sm3.h>}. + +@deftp {Context struct} {struct sm3_ctx} +@end deftp + +@defvr Constant SM3_DIGEST_SIZE +The size of a SM3 digest, i.e. 32. +@end defvr + +@defvr Constant SM3_BLOCK_SIZE +The internal block size of SM3. Useful for some special constructions, +in particular HMAC-SM3. +@end defvr + +@deftypefun void sm3_init (struct sm3_ctx *@var{ctx}) +Initialize the SM3 state. +@end deftypefun + +@deftypefun void sm3_update (struct sm3_ctx *@var{ctx}, size_t @var{length}, const uint8_t *@var{data}) +Hash some more data. +@end deftypefun + +@deftypefun void sm3_digest (struct sm3_ctx *@var{ctx}, size_t @var{length}, uint8_t *@var{digest}) +Performs final processing and extracts the message digest, writing it +to @var{digest}. @var{length} may be smaller than +@code{SM3_DIGEST_SIZE}, in which case only the first @var{length} +octets of the digest are written. + +This function also resets the context in the same way as +@code{sm3_init}. +@end deftypefun + @node Legacy hash functions @subsection Legacy hash functions @@ -1256,6 +1302,7 @@ The last three attributes are function pointers, of types @deftypevrx {Constant Struct} {struct nettle_hash} nettle_sha3_256 @deftypevrx {Constant Struct} {struct nettle_hash} nettle_gosthash94 @deftypevrx {Constant Struct} {struct nettle_hash} nettle_gosthash94cp +@deftypevrx {Constant Struct} {struct nettle_hash} nettle_sm3 These are all the hash functions that Nettle implements. @end deftypevr @@ -3775,8 +3822,8 @@ There are abstract functions that use a pointer to a @code{struct nettle_hash} to represent the underlying hash function and @code{void *} pointers that point to three different context structs for that hash function. There are also concrete functions for @acronym{HMAC-MD5}, -@acronym{HMAC-RIPEMD160} @acronym{HMAC-SHA1}, @acronym{HMAC-SHA256}, and -@acronym{HMAC-SHA512}. First, the abstract functions: +@acronym{HMAC-RIPEMD160} @acronym{HMAC-SHA1}, @acronym{HMAC-SHA256}, +@acronym{HMAC-SHA512}, and @acronym{HMAC-SM3}. First, the abstract functions: @deftypefun void hmac_set_key (void *@var{outer}, void *@var{inner}, void *@var{state}, const struct nettle_hash *@var{H}, size_t @var{length}, const uint8_t *@var{key}) Initializes the three context structs from the key. The @var{outer} and @@ -3963,6 +4010,29 @@ This function also resets the context for processing new messages, with the same key. @end deftypefun + +@subsubsection @acronym{HMAC-SM3} + +@deftp {Context struct} {struct hmac_sm3_ctx} +@end deftp + +@deftypefun void hmac_sm3_set_key (struct hmac_sm3_ctx *@var{ctx}, size_t @var{key_length}, const uint8_t *@var{key}) +Initializes the context with the key. +@end deftypefun + +@deftypefun void hmac_sm3_update (struct hmac_sm3_ctx *@var{ctx}, size_t @var{length}, const uint8_t *@var{data}) +Process some more data. +@end deftypefun + +@deftypefun void hmac_sm3_digest (struct hmac_sm3_ctx *@var{ctx}, size_t @var{length}, uint8_t *@var{digest}) +Extracts the @acronym{MAC}, writing it to @var{digest}. @var{length} may be smaller than +@code{SM3_DIGEST_SIZE}, in which case only the first @var{length} +octets of the @acronym{MAC} are written. + +This function also resets the context for processing new messages, with +the same key. +@end deftypefun + @node UMAC @subsection @acronym{UMAC} @cindex UMAC -- 2.32.0

2 1

[PATCH v2 0/4] Introduce OSCCA SM3 hash algorithm
by Tianjia Zhang 06 Dec '21

06 Dec '21

Add OSCCA SM3 secure hash generic hash algorithm, described in OSCCA GM/T 0004-2012 SM3, the corresponding English specification: http://www.gmbz.org.cn/upload/2018-07-24/1532401392982079739.pdf Tianjia Zhang (4): Add OSCCA SM3 hash algorithm testsuite: add test for SM3 hash function hmac: add support for SM3 hash function nettle-benchmark: bench SM3 hashes Makefile.in | 7 +- examples/nettle-benchmark.c | 2 +- hmac-sm3-meta.c | 47 +++++++ hmac-sm3.c | 59 +++++++++ hmac.h | 19 +++ nettle-meta-hashes.c | 1 + nettle-meta-macs.c | 1 + nettle-meta.h | 2 + sm3-meta.c | 42 ++++++ sm3.c | 251 ++++++++++++++++++++++++++++++++++++ sm3.h | 82 ++++++++++++ testsuite/.gitignore | 1 + testsuite/Makefile.in | 2 +- testsuite/hmac-test.c | 6 + testsuite/meta-hash-test.c | 3 +- testsuite/meta-mac-test.c | 1 + testsuite/sm3-test.c | 20 +++ 17 files changed, 540 insertions(+), 6 deletions(-) create mode 100644 hmac-sm3-meta.c create mode 100644 hmac-sm3.c create mode 100644 sm3-meta.c create mode 100644 sm3.c create mode 100644 sm3.h create mode 100644 testsuite/sm3-test.c -- 2.32.0

2 8

Re: ANNOUNCE: Serious bug in Nettle's ecdsa_verify - Critical Confirmation
by nisse＠lysator.liu.se 06 Dec '21

06 Dec '21

"Jayakumar, Jaikanth" <jaikanth.jayakumar1(a)optum.com> writes: > There is a small confusion, I believe the bug reported here > (https://lists.lysator.liu.se/pipermail/nettle-bugs/2021/009457.html) > is related to CVE-2021-20305, right ? and this (CVE-2021-20305) is > fixed in version 3.7.2. Which *two* problems are you asking about? The problem referred to as https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-20305 was fixed in nettle-3.7.2. Then there was a different problem, in RSA decryption, https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-3580, fixed in nettle-3.7.3. > In the case it is the same, it would help big time if the CVE was > mentioned somewhere in the bug announcement thread. I'll try to remember to mention relevant CVE ids in future release announcements. Would help to also document in the NEWS file? Regards, /Niels -- Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance.

1 0

← Newer
1
2
3
4
5
6
7
...
218
Older →

Jump to page:

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