nettle-bugs

nettle-bugs@lists.lysator.liu.se

2208 discussions

[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 23 Oct '21

23 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 23 Sep '21

23 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 21 Sep '21

21 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 05 Sep '21

05 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

Is there an equivalent to curve25519_mul for ECC keys?
by Nicolas Mora 17 Aug '21

17 Aug '21

Hello, I'm wondering if there is a function of a combination of functions to perform a DH computation using ECC keys and their parameters "struct ecc_point *pub1, struct ecc_scalar *key2"? /Nicolas

2 2

[S390x] Optimize SHA256 and SHA512 compress functions
by Maamoun TK 14 Aug '21

14 Aug '21

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

1 0

[AArch64] Optimize AES with fat build support
by Maamoun TK 31 Jul '21

31 Jul '21

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

1 0

← Newer
1
...
5
6
7
8
9
10
11
...
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