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

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.

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.

This has been solved in 2.2.26 commit rGc75fd75532

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.

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

Regression with no-unicode font on Windows: T5491

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

Hello Mr. Koch,

Please run

Regression for keyserver search by mail address: T5497

Hello Mr. Koch,

Are you using Powershell or another non-standard shell? Which windows version are you using? Do you use default-key in gpg.conf? Do you have a smartcard inserted?

I set the priority 'High' as Yubikey NEO is the last one with source code available, IIUC.

@kianga
Thanks for your log.

I was just about to open a similar bug report, but I think this might be related. I’m also having trouble getting my Yubikey NEO to work with the latest update, however my log output looks different (see below) and this is on Windows (10 Pro, 21H1, build 19043.1055).

Thank you @werner I will apply the patch and recompile the .28 version for myself.

Fix will eventually go into 2.2.29. If there is enough public demand we will do a new Windows installer earlier.

Regression Yubikey NEO: T5487

@dkg
If we support native X25519 format, multiple representations will be possible (there are 32 ways, at least) for a single secret key, because it's the feature of X25519.

@werner
My patch is for the case if it's better to accept such a key of OpenPGP.
I don't know if it's better or not (yet). The purpose of this patch is to show the point where OpenPGP secret part translates into libgcrypt secret key, concretely.

Do we want to encourage multiple cleartext wire-format representations of the same secret key?

JFYI: Original curve25519-donna (as well as Botan library, and OpenSSL) tweaks bits inside of the exponentiation function, so secret keys with or without tweaked bits would be equivalent and produce the same public key.

Works. My initial tests also failed because on Windows 64 the registry value has to be placed in the WOW6432NODE

Apologies,.. I used ctags on read_w32_registry_string and that jumped me to build-aux/speedo/w32/g4wihelp.c which has a read_w32_registry_string that does not expand....
Now I found the w32-reg.c in common which looks completely fine.

gniibe: Can you explain why an import shall modify the secret key? Form my understanding it is an invalid secret key and thus it can't be used. An import operation is different than the key generation.

For an implementation of Curve25519 routine, it is needed to tweak those bits.

Better to have in-line:

diff --git a/agent/cvt-openpgp.c b/agent/cvt-openpgp.c
index 53c88154b..b1d43227a 100644
--- a/agent/cvt-openpgp.c
+++ b/agent/cvt-openpgp.c
@@ -159,7 +159,21 @@ convert_secret_key (gcry_sexp_t *r_key, int pubkey_algo, gcry_mpi_t *skey,
                EdDSA flag.  */
             format = "(private-key(ecc(curve %s)(flags eddsa)(q%m)(d%m)))";
           else if (!strcmp (curve, "Curve25519"))
-            format = "(private-key(ecc(curve %s)(flags djb-tweak)(q%m)(d%m)))";
+            {
+              unsigned int nbits;
+              unsigned char *buffer = gcry_mpi_get_opaque (skey[1], &nbits);
+              unsigned char d[32];
+
+              if (nbits != 256)
+                return gpg_error (GPG_ERR_BAD_SECKEY);
+
+              memcpy (d, buffer, 32);
+              d[0] = (d[0] & 0x7f) | 0x40;
+              d[31] &= 0xf8;
+              gcry_mpi_release (skey[1]);
+              skey[1] = gcry_mpi_set_opaque_copy (NULL, d, 256);
+              format = "(private-key(ecc(curve %s)(flags djb-tweak)(q%m)(d%m)))";
+            }
           else
             format = "(private-key(ecc(curve %s)(q%m)(d%m)))";

"Curve25519" in libgcrypt was implemented before the standardization of X25519. There are two problems here: endianess and tweaking-bits.

I've mentioned this interop issue (and tried to propose clarifying language for the revised standard) in the IETF OpenPGP WG mailing list.

@dkg I mentioned it just because it was added as (part of the?) solution for Ed25519 issue, i.e. it is not something related to parsing of interoperable format but some further processing when secret key part is sent to the gpg-agent in some intermediate format.

I think rGba321b60bc3bfc29dfc6fa325dcabad4fac29f9c has nothing to do with interoperable formats -- how things are stored in ~/.gnupg/private-keys-v1.d is unrelated to the interoperable transferable secret key format specified in 4880 or its revisions.

It is a different trust model. The man page has some information but we meanwhile doubt that it will ever be of great use. It is over designed to be actually useful. Just don't care. For further questions, please use the mailing lists.

If I did enable "tofu" that was not on purpose and I would not know how. What are tofu related questions? Is there a doc you can point me to? (Also is tofu.db an annoyance, and if so in which way?)

TOFU is not used by default and thus the tofu.db does only matter if you have enabled TOFU. Its purpose is to track the use of keys and it also stored information which you explictly gave in response to TOFU related questions.

Hello,
I just hit the same issue in Ubuntu 18.04.5 LTS with gpg version 2.2.4-1ubuntu1.4 and the command line provided on post https://dev.gnupg.org/T3972#127356 by dkg has helped me fix it.
The faulty key was from the Tor project.

Right. However, the SOS thing should then also be used for secret keys. (FWIW, I wrote my last comment while you were writing yours).

@werner isn't it used just for the public key? The secret x25519 key, exported by GnuPG, looks as following (in the way it is stored in file):

We invented the 0x40 compression flag to declare that as native curve point format. With the introduction of 448 things got more complicated due to the new IETF statdards for this curev. This is the reason for @gniibe's proposal for a Simple Octet String (SOS) as a new data type in OpenPGP.

Investigated it more, and it looks problem is not in incorrect endianness. Exporting x25519 secret subkey from the GnuPG showed up that we still need to change byte order.
After some experiments I ended up with the following self-explaining code piece, which makes RNP-generated keys to work with GnuPG for import:

repeat:
    if (botan_privkey_create(&pr_key, "Curve25519", "", rng_handle(rng))) {
        goto end;
    }
    /* botan returns key in little-endian, while mpi is big-endian */
    if (botan_privkey_x25519_get_privkey(pr_key, keyle.data())) {
        goto end;
    }
    if ((keyle[31] != 0x45) || (keyle[0] != 0x40)) {
        botan_privkey_destroy(pr_key);
        goto repeat;
    }
    if (botan_privkey_export_pubkey(&pu_key, pr_key)) {
        goto end;
    }

Well, we have always expanded envvars in registry values. You need to create the value as an REG_EXPAND_SZ type, though.

Thanks for investigations! Indeed, we do change byte order when storing/loading private key, as MPI should be big-endian, while curve25519 private key is little endian.
Do I correctly understand that we should store it in the MPI as it is (like with Ed25519)? It would be nice to clarify that in the RFC draft.
Another thing is that in my test even if byte order is not reversed in the secret key (including the attached test key), GnuPG still asks for password, reporting "error sending to agent: Bad passphrase".

The problem here appears to be that the "MPI" of the curve25519 secret key is not actually a standard-issue big-endian OpenPGP MPI -- it's an opaque bytestring expected to be passed to the underlying "native" implementation of x25519, in the same way that the secret key is handled for Ed25519.

investigating the subkey in python:

looks to me like you've got the byte ordering of the Curve25519 secret subkey reversed from the way that GnuPG expects it.

fwiw, gpg-agent complains that the keys don't match:

So what do you think is the threat here?

My concern is not a disloyal administrator, so I disagree with that priority.

I give this a low priority because all those infos are easily retrievable from config files.

Apparently only one of the secret keys is actually imported: the decryption key, but not the signing key.

Fixed in GnuPG 2.3.1, so, add the tag for GnuPG 2.2.

In T5401#145379, @werner wrote:

You can't use an EdDSA as subkey for encryption. Encryption is the default for a subkey unless you provide key usage parameters. Yes, we could flag this as an error, but I won't give it high priority.

Yes, this is an edge case very unlikely to be encountered. The odd thing is the generated "ed25519" subkey does somehow encrypt and decrypt without issue.

You can't use an EdDSA as subkey for encryption. Encryption is the default for a subkey unless you provide key usage parameters. Yes, we could flag this as an error, but I won't give it high priority. I would anyway suggest to use

Done for 2.2. and 2.3.

You are coming pretty late to the party ;-). Since 2.1.0 we don't use the ancient keyserver helpers anymore but reworked the entire network access. I even doubt that I can still test with a 2.0 version.

New option --force-sign-key for 2.2.28 and 2.3. Also added support to gpgme.

Here are example files produced by GnuPG 2.3-beta:
S part has preceding zero:

We could add compatibility mode for Ed25519 signature to conform well-formed MPI (expecting recovery).

Thanks for the information!
We'll update our CI.

MSYS builds are not supported. All kind of stuff may go wrong. Just don't use it. Please use the standard installer as listed at gnupg.org or install gpg4win (which includes this installer).

Sure, here is output:

2021-02-24T20:19:46.8671882Z + gpgconf --show-versions
2021-02-24T20:19:49.6868215Z * GnuPG 2.2.25-unknown (0000000)
2021-02-24T20:19:49.6871468Z MSYS
2021-02-24T20:19:49.6888515Z 
2021-02-24T20:19:49.6889344Z * Libgcrypt 1.8.7 (baacfb40)
2021-02-24T20:19:49.6889956Z version:1.8.7:10807:1.39-unknown:12700:
2021-02-24T20:19:49.6890454Z cc:90300:gcc:9.3.0:
2021-02-24T20:19:49.6891633Z ciphers:arcfour:blowfish:cast5:des:aes:twofish:serpent:rfc2268:seed:camellia:idea:salsa20:gost28147:chacha20:
2021-02-24T20:19:49.6892539Z pubkeys:dsa:elgamal:rsa:ecc:
2021-02-24T20:19:49.6893424Z digests:crc:gostr3411-94::md4:md5:rmd160:sha1:sha256:sha512:sha3:tiger:whirlpool:stribog:blake2:
2021-02-24T20:19:49.6894177Z rnd-mod:linux:
2021-02-24T20:19:49.6894666Z cpu-arch:x86:
2021-02-24T20:19:49.6895791Z mpi-asm:generic/mpih-add1.c:generic/mpih-sub1.c:generic/mpih-mul1.c:generic/mpih-mul2.c:generic/mpih-mul3.c:generic/mpih-lshift.c:generic/mpih-rshift.c:
2021-02-24T20:19:49.6897734Z hwflist:intel-cpu:intel-fast-shld:intel-bmi2:intel-ssse3:intel-sse4.1:intel-pclmul:intel-aesni:intel-rdrand:intel-avx:intel-avx2:intel-fast-vpgather:intel-rdtsc:
2021-02-24T20:19:49.6898968Z fips-mode:n:n:
2021-02-24T20:19:49.6899492Z rng-type:standard:1:2010000:1:
2021-02-24T20:19:49.6899888Z 
2021-02-24T20:19:49.6900359Z * GpgRT 1.41-unknown (0000000)
2021-02-24T20:19:49.6900739Z 
2021-02-24T20:19:49.6901208Z * Libassuan 2.5.4-unknown (0000000)
2021-02-24T20:19:49.6901605Z 
2021-02-24T20:19:49.6902048Z * KSBA 1.4.0-unknown (?)
2021-02-24T20:19:49.6902420Z 
2021-02-24T20:19:49.6902843Z * GNUTLS 3.6.15

Can you please run

As suggested in the linked question on stackexchange, I think that even if the error comes from the pinentry program, GnuPG could echo a more informative error than gpg: decryption failed: No secret key, such as terminal to little to show the pinetnry program, or something similar.

Hi Werner,
Thanks for the reply. Will try to reproduce this and get back to you. Our CI wasn't have an option to upload artifacts in case of failure.

Thanks for the report. Frankly the curses pinentries are not that widely tested.

With 2.2 the second works if the first passphrase prompt was canceled. Test invocation: