nettle-bugs

nettle-bugs@lists.lysator.liu.se

2205 discussions

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

[PATCH 0/4] Introduce OSCCA SM3 hash algorithm
by Tianjia Zhang 29 Nov '21

29 Nov '21

Add OSCCA SM3 secure hash generic hash algorithm, described in OSCCA GM/T 0004-2012 SM3. 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 | 41 ++++++ sm3.c | 250 ++++++++++++++++++++++++++++++++++++ sm3.h | 81 ++++++++++++ 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, 537 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

Curve point decompression
by Wim Lewis 10 Nov '21

10 Nov '21

I'm looking at implementing elliptic curve point compression a la SEC1 (admittedly, mostly to reduce the number of "feature not supported" code paths in a library, but it seems like a somewhat useful ability). Nettle/Hogweed already implements it internally for curve25519, but I want to implement it for the "secp" curves as well. Point compression is easy enough, but point decompression requires some curve math, potentially dependent on the specific curve, and some of it is redundant with what's already done in ecc_point_set(). So I was thinking about moving this functionality into Hogweed as a function along the lines of ecc_point_set_compressed(), which would take, instead of a y-coordinate, an int containing the sign/parity of the y-coordinate. So my question for the list and for the maintainers is, is this a reasonable API to add to Hogweed? Is there interest in including it in Hogweed if I were to take the time to turn it into a tidy patch?

3 10

[S390x] Optimize SHA3 permute using vector facility
by Maamoun TK 31 Oct '21

31 Oct '21

I've added a new patch that optimizes SHA3 permute function for S390x architecture https://git.lysator.liu.se/nettle/nettle/-/merge_requests/36 More about the patch in merge request description. regards, Mamone

2 4

secp256r1 mod functions
by nisse＠lysator.liu.se 22 Oct '21

22 Oct '21

Hi, a while ago I was asked to explain the 64-bit C versions of ecc_secp256r1_modp and ecc_secp256r1_modq (in ecc-secp256r1.c), and I found that a bit difficult. I've rewritten them, on branch https://git.lysator.liu.se/nettle/nettle/-/blob/secp256r1-mod/ecc-secp256r1…. Main difference is handling of the case that next quotient is close to 2^{64}: Old code allowed the quotient to overflow 64 bits, using an additional carry variable q2. New code ensures that next quotient is always at most 2^{64} - 1. For the new implementation, the modp function is a special case of the 2/1 division in https://gmplib.org/~tege/division-paper.pdf (would usually need 3/2 division to get sufficient accuracy, but reduces to 2/1 since the next most significant word of p is 0), and the modq function is a special case of divappr2, described in https://www.lysator.liu.se/~nisse/misc/schoolbook-divappr.pdf. I've not been able to measure any significant difference in speed (I get somewhat noisy measurements from the examples/ecc-benchmark tool), although I would expect the new code to be very slightly faster. These functions are not that performance critical, since the bulk of the reductions for this curve is done using redc, not mod. Any additional testing, benchmarking, or code staring, is appreciated. I will likely merge the new code to the master branch in a few days. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.

1 0

Structural fixes to the manual
by nisse＠lysator.liu.se 22 Sep '21

22 Sep '21

I've spent some time to improve structure (mostly non-text changes) of the manual. 1. Deleted all explicit node pointers in nettle.texinfo, instead letting makeinfo infer the node structure. This is the recommended way these days, according to texinfo documentation. 2. Changed the make rules producing nettle.pdf to use texi2pdf, instead of the chain texi2dvi + dvips + pstopdf. Most obvious result is that hyperlinks work better, and output file is slightly smaller. It's done in whatever way is default in texi2pdf, I haven't tried to check the details (e.g., what kind of fonts are used, and if they're all embedded in the file). 3. Split the huge Cipher functions node into one node per cipher. 4. Fixed a few places where urls or example code was too wide for the page. According to the docs (https://www.gnu.org/software/texinfo/manual/texinfo/html_node/URL-Line-Brea…), line breaks should be automatically added in urls when needed (and that's true also according to the docs for texinfo-6.7, which is what I have installed), but that didn't work at all when I tried it, so I've added a few explicit hints on how to break long urls. Also the @urefbreakstyle command wasn't recognized at all. Anyone here more familiar with texinfo that can explain? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.

1 0

← Newer
1
...
4
5
6
7
8
9
10
...
221
Older →

Jump to page:

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