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:

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.

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 <koenigni@student.ethz.ch> . This attack also applies to AMD, Intel, and ARM.

Can you please give more details and tell whether this is powerpc specific.

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.

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.

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.[1]

I pulled that branch with the commit w/o problems. However, as noted on your commit I won't apply that because it does not make any sense to change boilerplate blurbs for just an additional 's'. Nobody really uses that and browser can try to use https first. Sorry, there are more important things around.

(hm, i'm pushing apparently successfully to playfair.gnupg.org:/git/libgcrypt.git but it is not showing up here. if you want to fetch this patch, you can also find it on the http-to-https branch at https://gitlab.com/dkg/libgcrypt.git

I would prefer not to fix that. I did some experiments on replacing all the runtime parsed ECC constants by static data. Adding the other constants will then be simple.

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

I was talking to Thomas Dickey, who maintains Ncurses. Ncurses had a leak and he offered a config option to remove it. Ncurses config responds to --disable-leaks.

Dynamic loading of Libgcrypt is anyway not supported; those who do that are on their own.

I have not yet looked at the details but I do not consider one-time allocation a problem. If you want to silence ASAN it is possible to use gpgrt_annotate_leaked_object( foo). Dynamic loading of Libgcrypt is anyway not supported; those who do that are on their own.

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

The second and third arguments passed to xgcry_control seem to be lost when calling gcry_control.

Here are the next two failures I am seeing while testing libgrcypt. It appears to be related to GCRYCTL_INIT_SECMEM.

I'm still seeing a few odd outputs from make check, but I have not investigated them yet.

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

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

Here's a couple of awful hacks that get me through make check. Feel free to restate how awful they are; I know it is a bad thing to do.

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

Isn't the Sparc crypto instruction set only available in kernel mode?

This change has been pushed to repository.

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.

Thank you, it worked.

Thanks.

Applied to master. This is not suitable for 1.8

for whatever reason, i don't seem to be able to push to the branch on playfair, so i've also pushed the same commit over at https://gitlab.com/dkg/libgcrypt

Fixed in master.

Thanks for your report.
I think that your patch is too generous to run HMAC even if fips_mode is not enabled; Simply, we can stop calling integrity check when fips_mode is not active.

Reading https://en.wikipedia.org/wiki/Fedora_version_history, I guess that your kernel/glibc doesn't have working mlock.
It may work if running by root, though.

T4298: 'make check' with uninstalled library, which is building now (even if rpath doesn't work well) handles related issue, which was fixed for libgcrypt-1.9. Since this issue is for other libraries (libgpg-error, specifically), we could do something similar, but, it may be detecting LD_LIBRARY_PATH to fail with "Please remove LD_LIBRARY_PATH".

Applied.

Pushed to master, fixing about return value of getentropy. Tested on FreeBSD 12. Tested on FreeBSD 11 where getentropy is not available.