Pushed the change.

Considering the history of the translation, I concluded that it should be:
把密钥导出到一个公钥服务器上
(the typo was G-A where B-A was expected.)

@guzhongren
This is not GitHub, so, if you want, you need to learn how to submit your change in the form of patch, by using git.

Clone and checkout the branch as usual with Git. There is no web editor etc like you might know from github. For your request we need to wait for someone to check your request.

Hey, I found the typo which I reported hasn't been fixed https://dev.gnupg.org/source/gnupg/browse/master/po/zh_CN.po$1962

2.2.23 is an old version. We will soon release 2.2.28 which comes with an updated Simplified Chinese Translation, see rGb0a7132856

These are the versions:

Which version of Kleopatra are you using? And which operating system, e.g. Windows 10?

@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.

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.

In T5415#146808, @KasparEtter wrote:

Please excuse my late reply. I was busy with other things over the last few weeks.

Yes, putting disable-ccid into ~/.gnupg/scdaemon.conf works for me with GnuPG 2.3.1 under macOS Catalina (10.15).

I still don't understand what the problem is/was, so I cannot judge whether it's better to recommend this manual configuration for Mac users or to disable CCID by default on macOS.

I tried again after cloning the master branch, and I finally figured it out. Sorry for the trouble caused by this irrelevant question just submitted. thanks again.

Please read T5454 again. To get the listing I showed you need to use the latest gpgme from Git master.

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

Please excuse my late reply. I was busy with other things over the last few weeks.

@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.

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

Fixed for 1.8.8

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".

jitterentropy is also used in Linux kernel, and some people use clang to build it these days. So, I checked the kernel's one. It is simply compiled -O0 by Makefile, and there's no pragma line now (as of v5.13).

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:

Fixed for gpg < 2.3. To make the fix also work for gpg 2.3, T5462: gpgconf: Make gpg/keyserver option available again needs to be fixed.

Thank you, indeed it was my fault. After -enable-O-flag-munging it compiled (btw before that it spitted the same error in jitterentropy as the one referenced in the apple case, so maybe it's that?)

I don't think that it is a good idea to silence this warning. The pragma is esssential for proper random numbers and if clang hijacks a GCC's name space but implements something different it is better to have a warning than to fall into the pit full of dragons.

So, has this issue been solved?

In T5369#144864, @jukivili wrote:

That warning could be silenced by surrounding pragma with #ifdef __OPTIMIZE__ (with should be supported by GCC and Clang).

Thanks for your report.

A popular way is to export the subkey, delete the existing key pair, and then import the subkey back, so that the actual value of the master key will not appear in the key pair to protect the master key(The value of the master key will be backed up and stored in another safe place).
At this time, gpg -K will display the following for this key pair:

By " without a master key" do you mean a keypair where the private key for the primary key is missing?

Thanks. I push the fix of yours.

Done for all (libgcrypt (master, 1.9, and 1.8), libassuan, ntbtls, libksba, gpgme, gnupg (2.2 and 2.3).

Another solution to make life easier for gpgme users encountering this stuff would be if gpgme itself knows which uid is a DN and which is not, it could populate the gpgme_user_id_t.address field with content of the 1.2.840.113549.1.9.1 DN component. (or maybe gpgme_user_id_t.email, or both? as a user of gpgme, i don't really understand the difference between these fields)

fwiw, RFC 2253 is obsoleted by rfc 4514 -- which also doesn't have 1.2.840.113549.1.9.1 associated with "EMAIL", but does provide more detailed guidance for implementers of DN-to-string (and string-to-DN, to the extent that this is possible) conversions. Maybe the code should be updated to refer to the non-obsolete specification at least.

We translate only those OIDs from RFC-2253 to have a stable set of names in the libksba interface. If you need anything else, you need to do this yourself. For example gpgsm does this in in parse_dn_part, gpa has the code in format-dn.

I'm reporting this because the above message renders poorly in notmuch -- notmuch gets the user ID from gmime's g_mime_certificate_get_user_id, and gmime populates that field from the uids field of a gpgme_key_t object, and gpgme pulls uid information from gpgsm --with-colons.

Attached is a proposed patch.

Attached is an even worse PKCS7 blob, that should be validatable given reliance on ca.rsa.crt, but it will be rejected by gpgsm because the PKCS#7 bundle includes ca.rsa.cross2.crt in it.

OK, i have replicated this successfully with no ed25519 involved. here's the new intermediate cert:

Which NIST test suite are you referring to? It might not cover certificate pathfinding in the face of multiple cross-signed authorities.

@werner @ikloecker Any more thoughts / updates on this?

I do not have the time to analyse this in the context of our approved versions and to compare it to the NIST test suite. We also do not yet have support for ed25519 certificates.

Thank you. I checked what was missing and all looks good. But do not understand why the last gpgsplit xfree was not applied. We are leaving a block where this variable is dynamically allocated so even without error we need to free it.

thanks!

The error codes we use are a combination of code and location.

Thank you for your report.