Thank you for your report.

With the planned new context aware pubkey functions we technically could do this change w/o an ABI break.

Implementation Guidance for FIPS 140-3 and the Cryptographic Module Validation Program:
https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf

It is a matter of the used font. 2.2.29 will fix this problem.

In T5510#147840, @catenacyber wrote:

Got a new bug with regression range ccfa9f2c1427b40483984198c3df41f8057f69f8:6dfab8cfb94ccb485a15b13df3c499cbb06fddf2

curve=23 secp256r1
point=04555555ffffffffffffffffffffffffffffffffffffffffffffffffffffffffff73a865e2e128733884fb82ce625ade822f7d8a59a4dcc09266966cf1bf082856
bignum=2020ff2020202020202020202020202020202020202020202020202020202020
nettle: 0 045549408909dd3e772d7d669f8fba2248d334b54be3d18833223d944a328948c76198ac3b29712256dcd9ce1a09471f04267684e1edd45910d61d0b7847db2d58
gcrypt: 0 047a6ec0df23082c8ce54c2b536d76b30464f4e1e690bb77665d298f05f0bee6806e7db3377141cc71ee30dcb8ffb7240bc3ecf29132ab5eb4ae03c067cea0d561

Got a new bug with regression range ccfa9f2c1427b40483984198c3df41f8057f69f8:6dfab8cfb94ccb485a15b13df3c499cbb06fddf2

Same error message in Windows 8.1 x64 with the commands:
gpg --local-user 0x12345678 --sign-key 0xABCDEF12 or: gpg --default-key 0x12345678 --sign-key 0xABCDEF12.

Thanks a lot.

The original idea with the DNS code was just to source copy it but it turned out that we need to maintain it in GnuPG. Thus adding support for SHA256 makes sense to keep the code current in case we ever need to use it.

P192, P224, P256 and P384 are affected.

Is secp192r1 only curve that is giving wrong results?

Attached patch should fix the issue:

Thanks for reporting. There is two commits in that commit range, including https://dev.gnupg.org/rC9d909cb67e70fd792926ac1e2ab305b2cc96bc27 which adds fast reduction for NIST curves. So obviously something is wrong there. Is secp192r1 only curve that is giving wrong results?

Thanks for the report. Fixed.

Thanks for the report.

Needs to be tested with the current 2.2 version and a gcry_log_debugsxp should be added to the error output.

This will not be fixed. Brainpool is a standard feature of Libgcrypt and thus this is a bug in the used Libgcrypt installation. Note that although I recently fixed a new regression test for this case, I do not think that it is a good idea to add extra code for a broken Libgcrypt.

That might depend on your pinentry version. With a pre-1.1.1 pinentry and 2.2.28 I get this:

Will be in 2.2.29.

We need to see how to best fix this regression test for all Python versions.

FWIW: We have always refused to support shared mode because we anticipated such problems. However, we have a customer using their own cards along with card maintenance software of them. For their purposes PCSC_SHARED works just fine makes and this is why I decided to add --pcsc-shared along with a warning that it is in general not a good idea.

You need to protect only 2 critical set of ADPU sequence Sign and Decrypt. All other can be done not safely and have a minor impact. Get generation and cards unlock can be profitable with the transaction mode... but is very rare user makes another use of the card in same time he start that’s command. The check external interference can protect from a bad start. I have started this ticket because my card suffer in exclusive mode render the use of openpgp not really usable. When my card is an pcsc-shared mode, all it's OK but the daemon not able to restore after external interference. The correction proposed is OK but I have made recommendations because this can cause a bad applet switch... if the state does not restore before trying to switch applet all it's OK. I am not actually able to set directly differential code but I have described in the patch the change I have made and this make my card very happy. Not problems and the pin was queried if another application makes interference.

There are multiple issues here.

Thanks werner. That helps us to know that such test failure is not a deep issue that would push us to not deliver this version of gnupg on AIX.

Setting the gpg.program configuration value to "C:\\Program Files (x86)\\GnuPG\\bin\\gpg.exe" appears to resolve the issue.

It appears that Git ships with its own GnuPG program set, as can be seen in the attached image. I'll attempt to set the gpg.program setting in Git and see if that helps.

That looks all fine.

With the next release you will get only a warning:

gnupg-2.2/common/t-sexputil.c:467: test 0 failed: Unknown elliptic curve - ignored
This is likely due to a patched version of Libgcrypt with removed support for Brainpool curves

The only download I have executed with regard to gpg4win is from the gpg4win website. You can see the output of the command you specified below.

may give you some clues.

You are not using gpg4win with its included GnuPG 2.2 but some broken gpg version. The error message
"invalid size of lockfile" can only be emitted by the Unix version of GnuPG. Check for other installed gpg versions - there are sites which allows the download of for example a Cygwin version - these version can't work properly on Windows.

I did some test on Windows 10 using gnupg 2.2 with this patch and things work.

For testing ion Windows 10 you need to switch to "Legacy Console" and reboot.

I think that a patch like following is needed:

diff --git a/common/ttyio.c b/common/ttyio.c
index c385700de..55468bdf0 100644
--- a/common/ttyio.c
+++ b/common/ttyio.c
@@ -236,7 +236,21 @@ w32_write_console (const char *string)
   n = wcslen (wstring);

When console font is not a Unicode font, it seems that the WriteConsoleW function may return ERROR_GEN_FAILURE.

Hello Mr. Koch,

Sorry for the expired certificate.

Fix: "I Know so few about gnupg, thus I'm not sure I COULD add test cases, probably not. "

Hi,
The site now shows: "NET::ERR_CERT_DATE_INVALID" and I have a limited access to the web page.
Thanks for you explanation. However, I now so few about gnupg, thus I'm not sure I cannot add test cases, probably not. I'll see later if we have to provide on AIX a behavior different than the one of RedHat. Meanwhile, about your last proposal, yes it would be very useful to detect the case, print a warning, and skip the test. That would be helpful. Moreover, if the test deals with smartcards, we do not have on AIX, thus this test is very probably not useful in our environment.

Please run

The thing is that I added a test for a new function which uses standard curves of Libgcrypt. But here we are again at the RedHat mess: They support the NIST curves but they removed support for Brainpool curves. Both are very similiar curves just different parameters. Brainpool is just in Europe out of fear that the NIST curves are rigged by the the NSA. Now, why RedHat removed Brainpool is probably just a legal dept thing who didn't have a clue. The tin foil hats probably see a different reason.

• a patch change within scd/apdu.c dealing with a call of: pcsc_connect() since code has changed between the 2 versions: may this be the cause of the failure? (Edited: hummm this patch seems no more required. And I have the same failure without it).

Hi Werner,

Supported curves should be listed by

gpg --list-config --with-colons curve

I am not sure about Fedora, but RedHat used to remove ECC support from Libgcrypt; GnuPG requires these curves. As long as you don't use ECC you things will work despite of this failed test. The test is new to check and does not anticipate a broken Libgcrypt.

Replicated and fixed. Thanks for the report.

In fact, the trigger is not yubikey but the pcsc-shared flag... If the pcsc-shared flag is enabled, you do check for interference because you are in shared condition. It is not really a race condition because you can put the driver in transaction mode. It’s more a turn-by-turn games but you can lose the card context status between turn.
If you lock the patch only for yubikey I’m not able to test with my device. You can add my manufacturer ID in the test please.

Thank you for your explanation.

Thank you for your report.
I pushed the fix.

It's not a device is a card. NXP P71 security chips on the card in the 250Kb Rom with GlobalPlateform 2.1.1 It is not possible for a card to change CCID by applet. Card depends of reader CCID. When the card is on NFC readers, the FIDO applet is accessible not when it is on contact readers. But, when I am in NFC FIDO share the CCID. For the user point of view having multiple card for each applet is a bad thing to devices for one user. User search presently for multipurpose devices. DOOR, Login, Email-crypt, ledger. Actually for app is not recommended to use a reader in exclusive mode. By designs the card is stateless and for memory management deselect applet free mem from other applet. Presently in the best case the card has 144-255 KB of eeprom and 2k or ram.

If your token/card is not Yubikey and when it is possible to improve your token/card implementation, I would suggest not follow what Yubikey does for multiple applications; No multiple applications, but each feature with independent access (card+CCID, another card+different CCID, FIDO+HID, ...).

i'am not able to test... i can't build for win32. i have some trouble with my mingw32 installation and the miss match with library for build a functional version of gnupg for win32.
seem missing dll after make install folder. do you have instruction to setup dev environment for build win32 binary ? I use a ubuntu with minwg32. ntbtls seem missing ksba but libksba is already install verion 1.6.0 other project detect correctly ksba. it's seem is a little bit complicated juste for building scd project. a make it working correctly on windows environements.

The problem has been solved by me, but this and the problem are still very strange.