Related the changes, before we did the changes, we received two independent reports.

I am not sure whether this is related but when using Libgcrypt master and verifying a signature created with an ed25519 key, I get the error below with valgrind. Both with 2.2. current and 2.3. It does not happen with the current Libgcrypt 1.8.

Fixed in master.

A program like tests/t-mpi-point assumes gcry_mpi_print can do that.
We have a sort of regression with --debug option with t-mpi-point, the point q is not printed out correctly.

This requires re-evaluation of Libgcrypt to match the current FIPS specs.

Thanks for reporting this this. Your patch is correct.

Regarding Cygwin: The sources are a bit hard to find.
https://cygwin.com/packages.html
-> https://cygwin.com/packaging/repos.html
-> https://cygwin.com/git-cygwin-packages/
-> https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/libgcrypt.git;a=summary

Regarding GNU/kFreeBSD, my machine is using the FreeBSD 9.0 kernel, which does not yet have the security.bsd.unprivileged_mlock oid. Like what was mentioned here: https://lists.debian.org/debian-bsd/2014/08/msg00092.html

For Cygwin, I can't find how its libgcrypt package is built.
I found this for MSYS2: https://github.com/msys2/MSYS2-packages/tree/master/libgcrypt
This for Mingw-w64: https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-libgcrypt

I tested on FreeBSD. Same errors (t-secmen and t-sexp) are reproducible when we set:

On Solaris, the test errors are because of:

USAGE
       Because of the impact on system resources, the use of mlock() and
       munlock() is restricted to users with the {PRIV_PROC_LOCK_MEMORY}
       privilege.

OK, I identified the problem on OpenIndiana. The inclusion of <unistd.h> causes inclusion of <sys/types.h> before config.h. I'm going to fix this.

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

Yes, I need to optimize it.

@jukivili thanks for looking into this. If you want, you can go with "Marvin W. <git at larma.de>" or just keep as is.

Hi @slandden. Have you made any progress since the last time I asked?

For GNU/Linux or GNU/kFreeBSD system, libgcrypt 1.8 with libgpg-error 1.36 has no problem in Debian build:
https://buildd.debian.org/status/package.php?p=libgcrypt20

In solaris11openindiana-log2, we have two errors: one for ulong, and another for ushort.
I fixed the former. It is because of our mistake of using ulong before it is handled by libgcrypt/src/types.h. In the first place, it is implemented by "unsigned long", so, there is no need to use ulong here.

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).

It looks good.

Oh, no worries! Just wanted to confirm, that's all.

I am about half way. Sorry for the slowness.

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

Hello,
Is anyone working on this? Just want to confirm.

El vie., 8 nov. 2019 8:19, johnmar (John Martinez) <noreply@dev.gnupg.org>
escribió:

Allow me to clarify. For bounty purposes, as long as the intrinsic implementation matches or beats OpenSSL performance, it is acceptable. There have been cases where the use of certain intrinsics may yield better performing, but sub optimal results.

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

C-based intrinsic implementations are discouraged.

See https://minerva.crocs.fi.muni.cz/ for a description of the timing attack.

I modified _gcry_ecc_fill_in_curve so that g_y has new value in eid4730.

That's my badness. I think that I haven't seen this problem, because I mainly use tokens (where keygrip difference doesn't matter, after --card-status).

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:

... https://lists.gnupg.org/pipermail/gcrypt-devel/2019-July/004760.html

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