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

SPARC T4 has crypto instruction set for AES, GCM, SHA1, SHA256, SHA512, Camellia and DES, that can be used from user-space too.

This change has been pushed to repository.

This change has been pushed to repository.

Email did not get through (should use plain old text email), so I prepared patch myself. See D477, https://dev.gnupg.org/D477

I'm not actually sure how workflow should be on the 'patches' interface at dev.gnupg.org.

_gcry_fast_wipememory2 should be changed to always just use explicit_memset when available:

This is largely solved.

I think commit https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=09c27280cc09798d15369b3a143036b7ab5ddd69 should be backported to 1.8 branch of libgcrypt.

This looks duplicate of https://dev.gnupg.org/T4317