Thanks for reporting this this. Your patch is correct.

Patch have been applied to master, https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=79ed620ec46adbb08f5cea6a4865a95a436e4109

Thanks for bug fix. I've prepared patch and send it to mailing list https://lists.gnupg.org/pipermail/gcrypt-devel/2020-January/004885.html. Let me know if Reported-by is ok/enough. I would have liked to put you as author of commit, but this Differential interface of quite horrible and does not give all the needed information (mainly "name <email>" format for git).

I've been wondering this also. I can start working on this.

Please note that C-based intrinsic implementation is the way to go now as that is the path chosen for PowerPC implementations in libgcrypt.

Poly1305 addition helper for ppc64 posted on mailing list: https://lists.gnupg.org/pipermail/gcrypt-devel/2019-September/004804.html

PowerPC SHA-256 and SHA-512 implementations with little bit more tuning committed. Most notably, SHA-512 on POWER8 now gives similar performance to OpenSSL:

Patches send to mailing list:
https://lists.gnupg.org/pipermail/gcrypt-devel/2019-August/004800.html
https://lists.gnupg.org/pipermail/gcrypt-devel/2019-August/004799.html

I'll start working on PowerPC GHASH implementation in September after SHA2 is done.

I'll start working on new PowerPC SHA2 implementations for libgcrypt in coming weeks.

Patches for PowerPC AES acceleration sent to mailing-list, based partly on initial work by Shawn Landden (@slandden): https://lists.gnupg.org/pipermail/gcrypt-devel/2019-August/004788.html

In D494#4450, @slandden wrote:

I will leave these in the main file, as they might benefit from "static", and I do not want to rely on LTO for that.

Thanks. I really like this Altivec intrinsic approach. I might reimplement rest of the bulk block cipher functions this way later (if I ever get PPC HW access).

Would it be good to have interface for getting buffer size for different algos in this new interface? ... Similar as 'gcry_md_get_algo_dlen' for digest results.

Have you considered working on bulk CFB-decryption and OCB-enc/dec? Those are the block cipher modes used by GnuPG (OCB is new AEAD mode to be used starting with 2.3).

I've added few new CTR test vectors to tests/basic.c for checking 32-bit and 64-bit carry overflow cases, rC971d372f512ff6805d5b8b54e9ac1446f3f66643

ECB is not bulk optimized in libgcrypt. I've send patches to add this in past but this was rejected on grounds that ECB is insecure and should not be used.

Consider using tests/bench-slope to get cycles/byte results so they can be compared with https://github.com/dot-asm/cryptogams/blob/master/ppc/aesp8-ppc.pl#L34

I've prepared patch for statically defining mpiutil contants, but I can leave it out and not push to master.

That type of variadic macro is GCC extension, see https://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html

Maybe cleaner option for mpi/mpiutil.c would be to statically allocate the constants