Poly1305 addition helper for ppc64 posted on mailing list: https://lists.gnupg.org/pipermail/gcrypt-devel/2019-September/004804.html
Sun, Sep 15
Fri, Sep 6
Tue, Sep 3
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:
Sun, Sep 1
Sat, Aug 31
Thu, Aug 29
Mon, Aug 26
Sun, Aug 25
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
Fri, Aug 23
Aug 16 2019
Aug 13 2019
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.
Aug 2 2019
Jul 18 2019
@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.
Jul 17 2019
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.
Jul 16 2019
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.
Jul 15 2019
Jul 10 2019
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?
Jul 8 2019
Jun 25 2019
Jun 23 2019
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.
Jun 22 2019
This bug has been assigned CVE-2019-12904. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12904
Jun 21 2019
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).
Jun 20 2019
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?
Jun 6 2019
Jun 3 2019
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:
May 30 2019
May 29 2019
Thanks for taking the time to describe this attack vector. We will need to study this closer to balance such a change with other side effects of this.
May 28 2019
I do not have a PoC (or much interest in making one, I have too many more important things to do), but I believe this to be correct, based heavily on PPC knowledge of Nicolas König <email@example.com> . This attack also applies to AMD, Intel, and ARM.
Can you please give more details and tell whether this is powerpc specific.
May 25 2019
No sorry, we won't do that for the regular source. However, the full source for the binary installer is xz compressed. That is because we are legally required to publish the source but in reality the source ist not used and weel, to build you have lots of other requirements with xz being the simplest one.
May 24 2019
May 23 2019
May 21 2019
I don't see why the documentation needs to be fixed. gcry_sexp_canon_len returns 0 for certain and s-expressions, meaning tha the s-expression is not valid. After all the s-expression code in libgcrypt does not claim to be a general purpose parser for s-expression but is targeted towards Libgcrypt needs.
By marking this as "wontfix", you appear to be saying that you won't even fix the documentation to describe the constraints that gcrypt intends to enforce. This is surprising to me.
Perl would be okay for maintainer mode but not for regular builds. The reason is that perl is already used by autotools but a build shall still be possible w/o perl.
May 20 2019
I'm looking into doing a pretty epic hack of using the switch_endian syscall to speed this up.
I don't know. That would make it a relatively easy transplant. We've also used the Cryptogams code as a reference for Golang enhancements, if that helps. I'd welcome guidance on the matter from a maintainer.
Would the maintainers accept having perl in the repository? Linux does it.