There are still problems with libtool; see recent Debian problems on building
gnupg for Windows. Thus we won't chnage libtool for 1.7.0.

(The patch has been applied to 1.6 and master)

Well it took quite some time but I have now commited all 10 patches to master.
I have a fixed a few things (mostly style).

I have not yet added the Fedora patch. I'll ask Tomáš whether he can send me a
signed off patch.

Applied to master will go into 1.7.

I tried the patch and the problem hasn't shown up for me after an hour of
continuously running the test suite, so it looks fixed! Thanks for the fast
turnaround on this tricky problem.

By "all zero", I mean that a limb can be with bits of all zeros, so that e =
ep[i] can be zero.

D359: 783_mpi-pow-normalize-expo.diff

Thank you very much. It is reproducible for me, too. I located the issue.
I think that it is reproducible for any libgcrypt (even < 1.5.3).
With the patch attached, problem seems to be gone.
Problem is that the DH exchange introduced in the commit fc4a969a in libssh2,
the EXPO argument is coming without normalization, so, count_leading_zeros
results undefined value on IA-32.
In libssh2, it's random bytes, so, it can be all 0.

A couple more point: openssh must be installed on the system so the test suite
will work. Also, the problem seems to have started in commit fc4a969a in libssh2.

This recipe generally causes a hang within no more than 5 minutes of running
through the test suite on my system. libcrypt is assumed to be installed in the
normal location, or set PKG_CONFIG_PATH appropriately. Run "src/curl --version"
to make sure it says libssh2/1.7.0_DEV to prove it's picked up the right libssh2
and "ldd src/.libs/lt-curl" to make sure it's using gcrypt.

git clone https://github.com/libssh2/libssh2.git
cd libssh2
./buildconf
./configure --prefix=/tmp/install --with-libgcrypt
make -j6 && make install
cd ..
curl -O https://curl.haxx.se/download/curl-7.47.1.tar.lzma
tar xaf curl-7.47.1.tar.lzma
cd curl-7.47.1
PKG_CONFIG_PATH=/tmp/install/lib/pkgconfig ./configure --enable-debug
--without-ssl --with-libssh2
make -j6
while true; do make -j6 test TEST_Q='-a -p -n SFTP SCP'; done

If it is difficult for you to minimize your test case, as long as it is
reproducible, please let us have your test case. We'll try to figure out the bug.

Note that we need a 64 bit Libgcrypt for a 64 bit GpgOL. Thus checking that
rndw32.c works proberly on 64 bit Windows will soon be important.

I can't show you math proof at hand, but I'm confident enough J can't be negative.
This implementation of mpi_powm was introduced in October 2013.

libgcrypt 1.5.3 was the one with old implementation.

The code that's failing is single threaded and passes valgrind, address sanitizer
and undefined sanitizer tests. I can't think of how the stack could be corrupted
from outside the routine, except perhaps that a signal handler is involved. If
you're confident that j could never be negative in the normal case, then I'll try
tracking down how that could happen.

Thank you for your experiment.
I suspect other cause(s). In the code itself, there is no possibility J can be
negative. However, it could be possible, in practice, when the stack is
corrupted because of wrong allocation of memory or by other threads.

I tried doing exactly that, but it didn't reproduce the problem. I assumed that
either the internal representation of the input values set up in my test program
with gcry_mpi_scan() and gcry_mpi_set_ui() subtly differed from the ones
encountered in production, or there was some code path that uses an uninitialized
variable, but I don't know if either theory could be the case.

When you get negative value for J on entry of the for loop, you can examine four
arguments to _gcry_mpi_powm. And then, you can write standalone program to
emulate it. Debugger or printf.

In what condition can J can be initialized < 0?
Do you have some idea?

Thanks for writing the report - that is better than having your report ticked
only in my mail folder.

on vacation, will test when I am home.

I believe 1.6.5 has no problem.

This has been fixed in 1.6.4 or earlier.
We won't fix it for 1.5.

Thanks for this info

to be released with 1.6.5

This _might_ have been fixed in 1.6.4

Thanks for the report. Please add the stack trace here (either inline or as an
attactment) so that it does not get lost. Thanks.

Here's something i got from running dbx with benchmark (with "check -access" option
to detect illegal memory access):

dbx benchmark

Reading benchmark
Reading ld.so.1
Reading libgcrypt.so.20.0.4
Reading libgpg-error.so.0.17.0
Reading librt.so.1
Reading libsocket.so.1
Reading libc.so.1
Reading libgcc_s.so.1
Reading libaio.so.1
Reading libmd.so.1
Reading libnsl.so.1
(dbx) check -access
access checking - ON
(dbx) run --verbose
Running: benchmark --verbose
(process id 20779)
Reading rtcapihook.so
Reading libdl.so.1
Reading rtcaudit.so
Reading libmapmalloc.so.1
Reading libgen.so.1
Reading libm.so.2
Reading libm_hwcap1.so.2
Reading libc_psr.so.1
Reading rtcboot.so
Reading librtc.so
RTC: Enabling Error Checking...
RTC: Running program...

...

Algorithm generate 100*sign 100*verify

RSA 1024 bit Read from uninitialized (rui):
Attempting to read 1 byte at address 0xffbfeba8

which is 312 bytes above the current stack pointer

stopped in add_randomness at line 1085 in file "random-csprng.c"
1085 rndpool[pool_writepos++] ^= *p++;
(dbx)

Hope this helps solve the issue.

I'm sorry, do you mean the zip file that i uploaded earlier? That was just
screenshots of the output message which i listed in my second post. It's just
benchmark and keygen, and i am pretty sure both errors are related to ECC key
generation.

It's my first time using this site, please let me know if i need to provide more
information. And thanks!

And that other bug report was?
You have full user permissions and thus you may comment on all bug reports.

Can't seem to edit my first post, so create this second post to provide extra info.

Ran all tests in libgcrypt/libgcrypt-1.6.4/tests directory, benchmark and keygen
failed. Here's the output:

./benchmark --verbose

.
.
.

Algorithm generate 100*sign 100*verify

RSA 1024 bit 310ms 1040ms 50ms
RSA 2048 bit 2370ms 7070ms 150ms
RSA 3072 bit 15950ms 21660ms 340ms
RSA 4096 bit 139410ms 47920ms 620ms
DSA 1024/160 - 600ms 820ms
DSA 2048/224 - 2920ms 3940ms
DSA 3072/256 - 6730ms 9520ms
ECDSA 192 bit
Segmentation Fault (core dumped)

./keygen --verbose
keygen: creating 1024 bit RSA key
keygen: creating 512 bit RSA key with e=257
keygen: creating 512 bit RSA key with default e
keygen: public exponent: 29
keygen: creating 1024 bit Elgamal key
keygen: creating 5 1024 bit DSA keys
keygen: creating 1536 bit DSA key
keygen: creating ECC key using curve NIST P-521
Segmentation Fault (core dumped)

the OS shows ld is resolved to GNU ld:
$ which ld
/home/alelai/binutils-2.25/bin/ld

not sure why configure script pick up the ccs version.
I tried:
export LD=/home/alelai/binutils-2.25/bin/ld

configure shows:
...
checking if the linker (/home/alelai/binutils-2.25/bin/ld) is GNU ld... yes
...
(please see the attached new config.log.20160107)

But the error occurred:

Assembler:

"/var/tmp//ccFCDwOq.s", line 25 : Syntax error
Near line: " addl $(Loop-L0-3),%eax"

Makefile:590: recipe for target 'mpih-add1-asm.lo' failed
make[2]: * [mpih-add1-asm.lo] Error 1
make[2]: Leaving directory '/home/alelai/libgcrypt-1.6.4.src/mpi'
Makefile:477: recipe for target 'all-recursive' failed
make[1]: * [all-recursive] Error 1
make[1]: Leaving directory '/home/alelai/libgcrypt-1.6.4.src'
Makefile:408: recipe for target 'all' failed
make: *** [all] Error 2

According to the posted config log this seems to be about
SunOS 5.10 on i86.

The extra option CC=-m32 is used with configure.

gcc versions is 5.2.
The linker is /usr/ccs/bin/ld, i.e. not GNU ld.

or well, gcrypt-devel in this case.

Duplicate of T1701

Please do not postarbitray pacthes to the tracker. Patches need to go to
gnupg-devel instead.

I'd be happy to implement this, but it is not clear to me how. Merely base64
encode the default representation? Or the canonical representation?

Pretty old. We should re-evaluate this for the 1.7 release.

The patches are now rebased on top of f7505b550dd591e33d3a3fab9277c43c460f1bad.

In addition to these a modified rsa generator is needed to be FIPS 186-4 compliant.

We ended up using this patch from Fedora:
http://pkgs.fedoraproject.org/cgit/libgcrypt.git/tree/libgcrypt-1.6.3-rsa-fips-keygen.patch

D253: 718_0011-Fix-testsuite-after-the-FIPS-adjustments.patch

D254: 717_0010-Add-new-pss-option-to-fipsdrv.patch

D255: 716_0009-Add-possibility-to-specify-salt-length-for-PSS-verif.patch

D256: 715_0008-fipsdrv-Add-support-for-RSA-keygen-tests.patch

D257: 714_0007-Fixes-for-RSA-testsuite-in-FIPS-mode.patch

D258: 713_0005-Use-2048-bit-RSA-keys-for-selftest.patch

D259: 712_0004-Disable-non-allowed-algorithms-in-FIPS-mode.patch

D260: 711_0003-PBKDF2-add-upper-bound-for-derived-key-length.patch

D261: 710_0002-ECDSA-adjustments-for-FIPS-186-4.patch

D262: 709_0001-DSA-adjustments-to-conform-with-FIPS-186-4.patch

For 1.6, please see:

    commit d501cc4edd55d3953d7581b3f8ff0c348df31ef0
    commit 24f6c65e36edec13aa781862ff1ff45ca3e99b99

Please test.

Thank you for the patch. I apply to master.
I'm going to apply to 1.6.

See attached for fix with sun studio's compiler.

D324: 692_patch-sunstudio