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 send to mailing-list, based partly on initial work by Shawn Landden (@slandden): https://lists.gnupg.org/pipermail/gcrypt-devel/2019-August/004788.html

Fixing t-lock is indeed a better solution however having an option to disable tests could be used in another context than fixing this issue.
For example, in the context of buildroot (which goal is to build a custom embedded linux system), this option could be used to save time during compilation as well as to save space on the embedded system.

Thanks for your report.
I think that adding an option for disabling tests is too much.
If it were AC_SUBST, we could use HAVE_PTHREAD in tests/Makefile.am.
In the current situation, just modifining t-lock is easier.

@werner I would be willing to share 20% to the reviewer of my patches. (or 25% in this case, as @jwilk went through the effort to even write a test to point out a bug in my code). However, so far that has been entirely @jwilk who has been reviewing my patches.

Please STOP adding such bug reports or feature requests. They are not helpful and such discussion are better done at the mailing list. In case you want to spend money to speed up things you may contact gnupg.com for a quote.

Please do not change the priority back. That is a maintainer's task. I consider this along with adding replicas of issues to a bit rude.

Please do not change the priority back without discussing this with the maintainer first. Thanks.

Check out the mailing list gcrypt-devel@

Folks, I was just wondering if I could get an update on where we are with this bug. It seems we aren't sure if it's a real issue or not. What's the latest thought?

Werner, I interpreted jwilik's patch as admission of a problem from upstream, and reported it as such to CVE. I felt that since this does not effect the main platforms (ARM and x86_64) it would not be a big deal. If I interpreted wrong, I am sorry.

I assigned the CVE, but yes it needs more facts.

Andreas, I wonder on which grounds you assigned a CVE for this claimed side-channel attack. The mentioned paper is about an old RSA side-channel and not on AES. I would like to see more facts than the reference to a guy who knows PPC pretty well.

This bug has been assigned CVE-2019-12904. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12904

Thanks, that's a good point. I'm adding gcry_ecc_get_algo_keylen.
I also changing the API for output (not allocating a buffer, but filling the buffer provided).

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.

Perhaps, returning allocated memory is not good. Filling the buffer for output would be better.

Shall we use secure buffer?

Thanks for taking this one.

This is problem of your setup of your build environment. Closing.

We got reports from Ubuntu users, perhaps, it's good to refer: