I backported the fix for 1.8.3.

Cherry-picked this for 1.8.3.

FIPS rules changed anyway and thus more rework will be needed anyway. I keep this open at low priorirty.

Thank you :)

Thanks. I only now noticed that this is the same as we already use for 32 bit MIPS. I have no more questions. Will push to master and the 1.8 branch.

Clang doesn't support the "h" inline asm constraint and the C version of umul_ppmm() works on MIPS64.

Your patch indicates that all clang versions for MIPS64 support this feature. Is my reading correct?

Got the question about this note from a user (in a internal email) and I see the problem that users do not have enough information to decide this. They do not know what the consequences of this note are (and suspect it to be the cause of error of they see it together with other problems). So to me it is more than a 'wish' as it will generate questions and leaves users in a situation where they cannot progress by their own in most of the situations.

It is not an error or even a warning but just a NOTE. Thus the user should decide. it is not even translated and most systems this is enabled anyway.

See also Filippo Valsorda's 32c3 talk about CSPRNGs.

@gouttegd : setting only-urandom at the distro level problematic due to two factors:

@dkg : Can’t this be solved at the distribution level? I assume the packager/maintainer for Libgcrypt on a given distribution should know whether the getrandom syscall is available on said distribution, so he could install a /etc/gcrypt/random.conf file with the only-urandom option.

Werner wrote:

we already use the getrandom system call if it is available

I am currently considering improvement of finalizer of libgcrypt, so, this matters.
Looking code, it would be better not to allocate and free the constant,
but use compile time constant data in .text section; Something like: const unsigned char ctr_null[DBRG_CTR_NULL_LEN].

To clarify: We already use the getrandom system call if it is available. To map /dev/random to /dev/urandom you can create a file /etc/gcrypt/random.conf with this line:

Note:
When we change the allocation, hmac256.c will not be standalone any more (as commented in the head of the file), and we will need to change the compile-command line to include libgpg-error.

I check this report again.
The test is single thread, IIUC.

Hmmm, needs to be investigated.

For secmem.c this is on purpose. For the others we should fix that.

Thanks. Indeed this should also use the x... wrappers. It is not severe because this value is only used as a fixed constant.
Thus we won't fix it in 1.8 but should do this 1.9.

I already talked with the upstream author and we figured a possible problem due to an non-locked use of the core function. The cause of this is

unsigned char *tmpval = ec->mem + ec->memlocation;
*tmpval = (*tmpval + 1) & 0xff;
ec->memlocation = ec->memlocation + ec->memblocksize - 1;
ec->memlocation = ec->memlocation % wrap;

which is non-atomic and will thus leads to the out-of-bounds deref. The EC object may only be used by one thread at a time.

It is reproducible on my Debian (stretch). I'm going to minimize the case.

Have posted in gcrypt-devel mailer.. thanks

Will be posting it in gcrypt-devel shortly.

Hope you've got the problem with the current naming conventions for arguments and the result by going them. We should either document the arguments properly or change the code as i have pointed out. Since the iterations argument used properly in the case PBKDF2 (type8) within the same wrapper api gcry_kdf_derive.

I would also suggest to discuss this at the gcrypt-devel list so that you can get get comments from others as well.

Your are looking at the libgcrypt code. Unfortunately that does not help us. What I would like to see are two protocol implementations, using sccryptone with libgcrypt and one with anoter scruypt implementation. Do they both work? If so, there is no bug in libgcrypt's code - at best the parameter have been given different names and we can point other name use in the docs.

Here's what i got from 1.8.1 code (downloaded from gnupg).

tests/t-kdf uses test vectors from an I-D and obviously works fine. Maybe that I-D has a different parameter naming than what is used in your examples. I simply can't say without researching the whole thing. Please let t me know a concrete bug where that KDF is not compatible with other implementations. As an example here is one of our test vectors:

The segfault from an openSUSE machine looks the same:

Okay, so on Suse we have the same problem w/o the somewhat intrusive changes of Fedora. The inetresting thing is that segv code part is the same as used in Linux.

The issue also occurs on openSUSE Tumbleweed:

libgpg-error is version 1.27: https://src.fedoraproject.org/rpms/libgpg-error/tree/f27
You can find the patches applied to libgcrypto here: https://src.fedoraproject.org/rpms/libgcrypt/tree/f27

Thanks for the report. I have a few questions, though
Which version of libgpg-error are you using?
What are the changes Fedora made to libgcrypt (and libgpg-error)?
Which CPU, what compile options and which compiler version?
Can you repeat this with a stock libgcrypt and libgpg-error?

Great, many thanks.

The fatal bug you reported can happen if the process is running out of secure memory. In general it should return an error but there is one place where we assumed the allocation would always succeed. This has meanwhile changed in the repo and will go into 1.8.2 However, this is not the real problem you have but just a wrong error behaviour.

Version 1.8.1. The full output is

Which libgcrypt version are you using (gpg --version shows it)

Add the tag of npth (forgotten).

Done for libassuan

Right, we can't do anything in Libgcrypt except for adding a way to return the open fds. This is the usual problem with libraries and the required closing of fds before an exec. Anyway the FIPS mode is questionable because it has not been adjusted for many years and does not take account newer requirements.

ECDH on Curve25519 is fully supported in libgcrypt. You can see GnuPG supports ECDH on Curve25519.
Lower layer routines (point addition and point duplication) are not implemented, though.
That's because ECDH only requires point multiplication and it is better to implement point multiplication by Montgomery Ladder for Curve25519.

Fixed both for master and 1.8 branch.

How about adding support with private in keyparam?

• (genkey(rsa(nbit 2048)(d xxxx)(p xxxx)(q xxxx)(u xxxx))) ; Only p and q, is OK
• (genkey(ecc(curve cv25519)(flags djb-tweak comp)(d xxx)))

Thanks for the list

Here is the list:

• libgcrypt
• libassuan
• ntbtls
• gpgme : autogen.sh is ready
• npth

Thanks for the information.
Closing, as I pushed rC94b84360ca55: Add OID information for SM3..

CESI also publishes a complete white pager documenting OID assignment in details. See http://www.cesi.cn/201612/1688.html and download the pdf. Search "10197" and I see the following info:

OK, I found: http://www.oidchina.cn/oid/release/1.2.156.10197.
站点： 国家OID注册中心
数字OID： 10197
中文OID：
英文OID： sca10197
应用范围： 密码标准化技术委员会

I use: 1.2.156.10197.1.401

I am now examining OID allocation.
I'll add the OID of SM3 into sm3.c.

In T3454#104310, @gniibe wrote:

This is my note.
If it is intended to be used to OpenPGP, GCRY_MD_SM3 should be assigned in OpenPGP standard.

In T3454#104309, @gniibe wrote:

Thank you. The diff doesn't include sm3.c. Could you please update?

This is my note.
If it is intended to be used to OpenPGP, GCRY_MD_SM3 should be assigned in OpenPGP standard.

Thank you. The diff doesn't include sm3.c. Could you please update?

This is the review request link: https://dev.gnupg.org/D449

Closing due to compiler error.

I recall something about this on our mailing list.

Pushed for master.

I prepared Libgcrypt for the 1.9 series, thus feel free to merge your patches to master anytime you like.

Bonus: less memory usage and performance improvement.

Done in a7bd2cbd.