nettle-bugs

nettle-bugs@lists.lysator.liu.se

2 participants
2193 discussions

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 20 Aug '21

20 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 16 Aug '21

16 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 13 Aug '21

13 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 30 Jul '21

30 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

[S390x] Fat build support for AES and GHASH
by Maamoun TK 24 Jul '21

24 Jul '21

I created a MR !31 <https://git.lysator.liu.se/nettle/nettle/-/merge_requests/31> that adds fat build support of AES and GHASH for S390x architecture. The MR's description has a brief overview of the modifications done to add the fat build support. regards, Mamone

2 6

[S390x] Optimize memxor
by Maamoun TK 22 Jul '21

22 Jul '21

I made a merge request !30 <https://git.lysator.liu.se/nettle/nettle/-/merge_requests/30> that optimizes memxor function for S390x architecture. I've attached a benchmark on a Z15 processor in the MR description. regards, Mamone

1 1

Fwd: [S390x] Optimize GHASH
by Maamoun TK 17 Jul '21

17 Jul '21

---------- Forwarded message --------- From: Maamoun TK <maamoun.tk(a)googlemail.com> Date: Sat, Jul 17, 2021 at 2:00 PM Subject: Re: [S390x] Optimize GHASH To: Niels Möller <nisse(a)lysator.liu.se> On Sat, Jul 17, 2021 at 1:37 PM Niels Möller <nisse(a)lysator.liu.se> wrote: > Maamoun TK <maamoun.tk(a)googlemail.com> writes: > > In another topic, I've optimized the SHA-512 algorithm for arm64 > > architecture but it turned out all CFarm variants don't support SHA-512 > > crypto extension so I can't do any performance or correctness testing for > > now. Do you know any CFarm alternative that supports SHA-512 and SHA3 > > extensions for arm64 architectures? > > Can you do correctness tests on qemu? (I've been using a crosscompiler > and qemu-user to test other ARM code, and that's also what the ci tests > do). > Sure, but I'm also concerned about the performance testing. I was always trying to get the best performance out of hardware-accelerated cores. > I have access to the systems listed on > https://gmplib.org/devel/testsystems, is any of those applicable? The > arm64 machines available includes one Cortex-A73 and one Apple M1. > Cortex-A73 doesn't support SHA-512 and SHA3 List of ARM microarchitectures - Wikipedia <https://en.wikipedia.org/wiki/List_of_ARM_microarchitectures> Cortex-A75 is the minimum architecture that has a full implementation of ARMv8.2-A which is the arch that introduced SHA-512 and SHA3 AArch64 Options (Using the GNU Compiler Collection (GCC)) <https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html> Cortex-A55 should support those extensions according to the list.

1 0

Re: [Aarch64] Optimize AES
by Maamoun TK 17 Jul '21

17 Jul '21

On Sat, Jul 17, 2021 at 1:46 PM Niels Möller <nisse(a)lysator.liu.se> wrote: > Maamoun TK <maamoun.tk(a)googlemail.com> writes: > > > It fits better to have one implementation per key size, I'll modify this > > patch to apply this approach. However, we need to merge the s390x branch > at > > first since it has a separate implementation for each key size. > > Right. With fat support in, is there anything else that is essential > before merging? > No, AES and GHASH have the full functionalities for S390x architecture in this way.

1 0

[S390x] Optimize GHASH
by Maamoun TK 17 Jul '21

17 Jul '21

I made a merge request !26 <https://git.lysator.liu.se/nettle/nettle/-/merge_requests/26> that optimizes the GHASH algorithm for S390x architecture. I've attached a benchmark in the description of merge request that describes the improvement of using GHASH accelerator over C implementation. I've also made two patches for fat build support of AES and GHASH for S390x architecture in addition to optimize memxor function using 'xc (xor storage-to-storage) instruction' Files · s390x-fat · Maamoun TK / nettle · GitLab (liu.se) <https://git.lysator.liu.se/mamonet/nettle/-/tree/s390x-fat> Files · s390x-memxor · Maamoun TK / nettle · GitLab (liu.se) <https://git.lysator.liu.se/mamonet/nettle/-/tree/s390x-memxor> I'll make merge requests for both patches after the current one being merged since they need to rebase on top of that patch. regards, Mamone

3 14

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