Fwd: [S390x] Optimize GHASH

[Maamoun TK]

-- Forwarded message -
From: Maamoun TK 
Date: Sat, Jul 17, 2021 at 2:00 PM
Subject: Re: [S390x] Optimize GHASH
To: Niels Möller 


On Sat, Jul 17, 2021 at 1:37 PM Niels Möller  wrote:

> Maamoun TK  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 
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))

Cortex-A55 should support those extensions according to the list.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: [Aarch64] Optimize AES

[Maamoun TK]

On Sat, Jul 17, 2021 at 1:46 PM Niels Möller  wrote:

> Maamoun TK  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.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: [S390x] Optimize GHASH

[Niels Möller]

Maamoun TK  writes:

> You are right, modern operating systems are supposed to have this
> functionality but accessing some program's memory is pretty easy nowadays,
> I think it's a good practice to clean behind the cipher functions for what
> it makes sense and whenever possible.

I think it's futile to try to do that thoroughly, e.g., code generated
by the compiler will not clear each stack frame on return (and I'm not
even ware of any compiler option to generate code like that). We have to
trust the operating system (where as usual, "trust" can also be read as
"depend on").

For the specific case of key material, it might make sense to go to a
little extra effort to not leave copies in memory, but other neetle code
doesn't do that.

> 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).

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.

Regards,
/Niels


-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: [S390x] Fat build support for AES and GHASH

[Niels Möller]

Maamoun TK  writes:

> I created a MR !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.

Merged, thanks! I wrote some comments asking for two followup changes
(avoid inline asm, and setting of FAT_TEST_LIST).

Do you think we're getting ready to merge the s390x branch to master?

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Re: [Aarch64] Optimize AES

[Niels Möller]

Maamoun TK  writes:

> I made this patch operate AES ciphering with fixed key sizes of 128-bit,
> 192-bit, and 256-bit, in this case I eliminated the loading process of key
> expansion for every round. Since this technique produces performance
> benefits, I'm planning to keep the implementation as is and in case
> handling uncommon key size is mandatory, I can append additional branch to
> process message blocks with any key size. What do you think?

There's no need to support non-standard key sizes. _nettle_aes_encrypt
should only ever be called with one of the constants _AES128_ROUNDS,
_AES192_ROUNDS, _AES256_ROUNDS as the first argument.

I think it's becoming clearer that we should make assembly for
_nettle_aes_encypt optional, in favor of separate entry points for
aes{128,192,256}_{en,de}crypt. I think you or I had an experimental
branch to do that.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
___
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs