Just more background what I'm doing with these tests. I started testing with set of different sized test files (generated from urandom) to detect any bugs in my changes, which try to reduce amount of memory copies in iobuf_read/iobuf_write. Size ranges for these test-files are 0...17408, 32256...66560 and 130560...132096 bytes. These files are encrypted with different settings (public key/symmetric/cfb/ocb/different algos) and then decrypted and decrypted file compared to original.

I tested the fix. It appears to break OCB encrypting files shorter than 65515 bytes:

$ gpg --batch --symmetric --passphrase=bug --output=enc_065514.gpg --rfc4880bis --force-aead --cipher-algo AES128 --compress-algo none plain_065514
$ ls -laF *065514*
-rw-rw-r-- 1 jussi jussi   100 Feb  22 18:51 enc_065514.gpg
-rw-rw-r-- 1 jussi jussi 65514 Feb  22 18:42 plain_065514
$ sha256sum plain_065514
5711955703f4d96f510ad5a660c3ccd0d01f0b2dd2561ba6586159ad941cbcde  plain_065514
$ gpg --batch --decrypt --passphrase=bug --output=- enc_065514.gpg | sha256sum
gpg: AES.OCB encrypted session key
gpg: encrypted with 1 passphrase
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  -

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?