nettle-bugs

nettle-bugs@lists.lysator.liu.se

3 participants
2194 discussions

[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

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

← 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