Benchmarking blog post that I linked tested GnuPG in symmetric mode, gpg --symmetric. I think symmetric case is important too from performance point of view, there is tools that use gpg --symmetric as bulk encryption/decryption backend (for example duplicity backup tool). Such encrypted files have tag3 (symmetric-key ESK) packet followed tag18 (encrypted and MDC) packet. Could existence of Tag18 packet in input be used as marker for input being rfc4880 and allow disabling those extra hash contexts? As I understand those hashes should not be needed with rfc4880 input (but I don't know all the historical details).

I planned to reply to your email on mailing-list, but I just have too little time.

Thanks for report. Those powerpc vector implementations expect that compiler optimizations are enabled and here provided CFLAGS did not have '-Ox' parameter. This could be worked around by introducing -O2 always when building those files (confiugre.ac & cipher/Makefile.am change) or using 'optimize' attributes to required functions (cipher/*-ppc*.c change).

Thanks for report. I got similar report earlier this week from gentoo user through email and made following patch for them to test. I'll push it to master soon.

Ok, I'll add.

DCO has not appeared on mailing-list. You can this from check list archives, https://lists.gnupg.org/pipermail/gcrypt-devel/2021-December/thread.html

I did some finishing touches on coding style:

Few comments on new patch:

Thanks, however I didn't see your email on mailing-list. Maybe the email got stuck on the way.

Please read doc/HACKING carefully on the process of sending DCO the right way.

Following patch should prevent assembly files being built at all with --disable-asm:

Thanks for your report.

Based on GCC bugzilla, affected released GCC versions are 11.1 and 11.2.

(ab | ba) >= 0 is used to make optimization analysis for compiler more difficult. I see that with (ab | ba) == 0, it would be much easier for compiler to conclude than loop could exit early as soon as first a[i] != b[i] is seen.

That crcalgo can be any digest algorithm and SHA256 seems best option to me.

In T5510#147840, @catenacyber wrote:

Got a new bug with regression range ccfa9f2c1427b40483984198c3df41f8057f69f8:6dfab8cfb94ccb485a15b13df3c499cbb06fddf2

curve=23 secp256r1
point=04555555ffffffffffffffffffffffffffffffffffffffffffffffffffffffffff73a865e2e128733884fb82ce625ade822f7d8a59a4dcc09266966cf1bf082856
bignum=2020ff2020202020202020202020202020202020202020202020202020202020
nettle: 0 045549408909dd3e772d7d669f8fba2248d334b54be3d18833223d944a328948c76198ac3b29712256dcd9ce1a09471f04267684e1edd45910d61d0b7847db2d58
gcrypt: 0 047a6ec0df23082c8ce54c2b536d76b30464f4e1e690bb77665d298f05f0bee6806e7db3377141cc71ee30dcb8ffb7240bc3ecf29132ab5eb4ae03c067cea0d561

Thanks a lot.

P192, P224, P256 and P384 are affected.

Attached patch should fix the issue:

Thanks for reporting. There is two commits in that commit range, including https://dev.gnupg.org/rC9d909cb67e70fd792926ac1e2ab305b2cc96bc27 which adds fast reduction for NIST curves. So obviously something is wrong there. Is secp192r1 only curve that is giving wrong results?