nettle-bugs

nettle-bugs@lists.lysator.liu.se

2191 discussions

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

[S390x] Optimize SHA1 with fat build support
by Maamoun TK 20 Sep '21

20 Sep '21

I made a merge request in the main repository that optimizes SHA1 for s390x architecture with fat build support !33 <https://git.lysator.liu.se/nettle/nettle/-/merge_requests/33>. regards, Mamone

2 10

[S390x] Optimize AES modes
by Maamoun TK 19 Sep '21

19 Sep '21

I made a merge request for optimizing AES modes on s390x architecture, the patch implements the optimized cores using cipher instructions that have been added to s390x arch in message security assist extensions. The patch uses the following functions: KM-AES-128 (ECB-AES128) KM-AES-192 (ECB-AES192) KM-AES-256 (ECB-AES256) KMC-AES-128 (CBC-AES128) KMC-AES-192 (CBC-AES192) KMC-AES-256 (CBC-AES256) KMAC-AES-128 (CCM-AES128, CMAC-AES128) KMAC-AES-192 (CCM-AES192) KMAC-AES-256 (CCM-AES256, CMAC-AES256) KMF-AES-128 (CFB-AES128, CFB8-AES128) KMF-AES-192 (CFB-AES192, CFB8-AES192) KMF-AES-256 (CFB-AES256, CFB8-AES256) KM-XTS-AES-128 (XTS-AES128) KM-XTS-AES-256 (XTS-AES256) KIMD-GHASH (GHASH) KMCTR-AES-128, KMA-GCM-AES-128 (CTR-AES128) KMCTR-AES-192, KMA-GCM-AES-192 (CTR-AES192) KMCTR-AES-256, KMA-GCM-AES-256 (CTR-AES256) KMA-GCM-AES-128 (GCM-AES128) KMA-GCM-AES-192 (GCM-AES192) KMA-GCM-AES-256 (GCM-AES256) The merge request has also a benchmark that measures the speed of optimized cores on s390x arch. I can't set up gitlab CI for automatic testing on s390x arch because qemu hasn't implemented cipher functions for this arch. However, there is an easy way to test the patch manually by requesting a free account on the LinuxONE Community Cloud, both short-term and long-term access are available. https://linuxone.cloud.marist.edu/#/register?flag=VM regards, Mamone

4 39

Reorganization of x86_64 aesni code
by nisse＠lysator.liu.se 04 Sep '21

04 Sep '21

I've merged a reorganization of the x86_64 aesni code to the master-updates branch for testing. This replaces the x86_64/aesni/aes-*crypt-internal.asm files with separate files for the different key sizes, as has been discussed earlier. And I've implemented 2-way interleaving, i.e., doing 2 blocks at a time, which gave a nice speedup on the order of 15% in my tests. I may be worthwhile to go to 3-way or 4-way, but I don't plan to try that soon. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.

2 1

Re: Build problem on ppc64be + musl
by Maamoun TK 21 Aug '21

21 Aug '21

Forcing ELFv2 abi doesn't work for big-endian mode as this mode has no support for ELFv2. ppc64 linux big-endian is deprecated, it' not unexpected to get such issues. Dropping big-endian support for powerpc could be an option to solve this issue but that will be a drawback for AIX (BE) systems. regards, Maamoun On Mon, Aug 16, 2021 at 10:54 PM Niels Möller <nisse(a)lysator.liu.se> wrote: > Stijn Tintel <stijn(a)linux-ipv6.be> writes: > > > I suspect this is because musl doesn't support the ELFv1 ABI on ppc64 at > > all, regardless of endianness. I've tried adding -mabi=elfv2 to CFLAGS, > > to force using the ELFv2 ABI, but the problem persists. Suggestions > welcome. > > I don't know that much about ppc64 abi issues myself. From your > description, it seems clear that it's a linker error, and that object > files corresponding to C source files somehow carry different "abi > version attributes" than object files corresponding to nettle's assembly > source files. > > As you've found, configuring with --disable-assembler works around the > problem, but to solve it properly, we'd need to understand why that is. > The assembler should not be invoked directly, but via the same $(CC) and > $(CFLAGS) as the C compiler. > > You'd need to compare those object files and how they're generated. > Compare the compiler command lines. You could perhaps use gcc -v to see > how gcc invokes the assembler in both cases. You can use gcc -save-temps > to look at the assembly files generated by gcc, and check if they use > some special pseudoops to specify the abi. You can use tools like > objdump or readelf to compare attributes in the object files. > > If you can figure out how to produce object files that are compatible > according to the linker, that may not be sufficient, though. You also > need to tweak the assembly files and related macros and configure checks > to use the right api. See powerpc64/README and powerpc64/machine.m4. As > I understand it, abi is currently selected depending on the endianness, > using v1 for big endian and v2 for little endian. > > It may need a configure test independent of endianness. Maybe there's > some predefined symbol we can check, similar to 32-bit/64-bit ABI checks > on other platforms? You could run something like > > powerpc64-openwrt-linux-musl-gcc -E -dM - </dev/null | sort > > With the powerpc64le-linux-gnu-gcc cross compiler I have, the closest > suspect I see is > > #define _CALL_ELF 2 > > Maybe that's the right thing to check? I don't have a big-endian system > or crosscompiler close at hand, but at least there's a bigendian > powerpc64-linux-gnu cross compile setup in the ci system hosted at gitlab. > > Regards, > /Niels > > -- > Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. > Internet email is subject to wholesale government surveillance. >

3 8

← Newer
1
2
3
4
5
6
7
8
9
...
220
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