Thanks for the reply!

Sorry for a bit late follow up. How do you calculate a public key? RNP's crypto backend, Botan, is calculating public key without taking in account bits which should be tweaked. I.e. both tweaked and non-tweaked secret keys would produce the same public key. The same is with decryption. Could it be the case that your implementation actually used those bits to calculate a public key?

@bigmomma Just for a quick check - did you try to use RNP's CLI command --edit-key --fix-cv25519-bits, as it's not clear from the message?

Fix for this issue landed RNP master, and will be included to the RNP v0.16.0 release.
Within fix:

• new keys will be generated with correctly tweaked bits
• using secret key with non-tweaked bits would issue a warning
• CLI command --edit-key [--check-cv25519-bits | --fix-cv25519-bits] added, allowing to fix older key

Argh, sorry for bugging. Clearing comment out - I simply missed fact that my tests are run with random messages, so with 5% probability another password will be interpreted as 'good' for the first SKESK.

Thanks for clarification, indeed attempt to decrypt data returns an error afterwards.

Thanks, Werner.
During further work on this got another issue:

Thanks for the replies, this makes things clear. We'll update RNP to correctly set/unset those bits while saving a generated secret key and a way to fix up previously generated keys.

@gniibe sorry for pinging, but this issue gets attention as TB users (with RNP OpenPGP backend) cannot import to GnuPG EdDSA secret key which was generated by RNP since it doesn't tweak bits when storing or exporting a secret key.
Should we update RNP to tweak those bits during storage to be more compatible (given that those bits doesn't make any difference)?

Do I correctly understand that issue will be resolved on GnuPG side by tweaking key bits before private-key import/and/or/operations?

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.

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

@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):

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

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

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

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

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.

Hm, got something similar on macOS runner as well (however, in this case secret key is generated by RNP, and then successfully imported by GPG) :

2021-02-19T10:49:42.8239220Z /tmp/rnp-local-installs/gpg-install/bin/gpg --homedir /var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/rnpctmp3ciohli5/.gpg --pinentry-mode=loopback --batch --yes --passphrase key2pass --trust-model always -o /var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/rnpctmp3ciohli5/cleartext.dec -d /var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/rnpctmp3ciohli5/cleartext.rnp
2021-02-19T10:49:42.8240980Z gpg: AES256.CFB encrypted session key
2021-02-19T10:49:42.8241480Z gpg: encrypted with 1 passphrase
2021-02-19T10:49:42.8242430Z gpg: encrypted with 1024-bit RSA key, ID 23295470BD33EA4A, created 2021-02-19
2021-02-19T10:49:42.8243090Z       "key2@rnp"
2021-02-19T10:49:42.8243580Z gpg: public key decryption failed: Corrupted protection
2021-02-19T10:49:42.8244650Z gpg: encrypted with 1024-bit RSA key, ID 3A9FE68E283F7439, created 2021-02-19
2021-02-19T10:49:42.8245220Z       "key1@rnp"
2021-02-19T10:49:42.8245690Z gpg: public key decryption failed: Bad passphrase
2021-02-19T10:49:42.8246250Z gpg: decryption failed: Bad session key

Attaching the full log:

Thanks for the reply. Not sure about GPGME/gpgme-json. Anyway, it still ends up in gpgme code, isn't it?
I used to modify gpgme sources to receive more information about the issue.
Looks like the next step would be to modify gpg-conf and see what's going on there, or leave it to the Thunderbird developers.

Thanks, Werner.
With the latest data everything works fine.
I also a problem with incorrect cipher state resetting if last chunk is 0-size.

Hi Werner, thanks.
Looks like our tests against GnuPG are passing now.
Can you please provide the password for this file as well? 'password' doesn't seem to fit.

I found another issue in current master of GnuPG. Probably you already noticed it - when GnuPG AEAD-encrypts input which is a multiple of chunk size, then incorrect chunk number is used in the last block (+1)
The same happens for decryption.
Here is debug output of 128-byte input decryption with 64-byte chunk len:

gpg: DBG: nonce: D0 33 CD AC B5 54 07 66 2C 5C 55 7F A9 F2 EF
gpg: DBG: authdata: D4 01 07 02 00 00 00 00 00 00 00 00 00
gpg: DBG: nonce: D0 33 CD AC B5 54 07 66 2C 5C 55 7F A9 F2 EE
gpg: DBG: authdata: D4 01 07 02 00 00 00 00 00 00 00 00 01
gpg: DBG: nonce: D0 33 CD AC B5 54 07 66 2C 5C 55 7F A9 F2 ED
gpg: DBG: authdata: D4 01 07 02 00 00 00 00 00 00 00 00 02
gpg: DBG: eof seen: holdback buffer has the tags.
gpg: DBG: nonce: D0 33 CD AC B5 54 07 66 2C 5C 55 7F A9 F2 EC
gpg: DBG: authdata: D4 01 07 02 00 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00 80

Hi Werner,
Looks like there is a problem on my side, I miscalculated data length (0x240 while it should be 0x280).
Other then this values are the same:

Please see the original file (hello.txt), CFB-encrypted to two passwords (hello.txt.cfb), and AEAD-encrypted (hello.txt.aead).
Passwords used are '1' and '2'.

Checked - it builds fine now. Thanks!