cannot import the result of gpg --export-secret-subkeys

[kaie]

We received a request to support a configuration that uses an offline primary key. We don't need to support generating such a scenario. However, we want to support a scenario, in which the user uses gnupg to create their keys, and then imports all public keys, and then imports the secret keys of all subkeys, but not the secret key of the primary key.

Procedure used: gpg --full-gen-key select 4 (rsa sign only)

gpg --expert --edit-key addkey 4 addkey 6 save

gpg --export --armor > pub.asc gpg --export-secret-subkeys --armor > subkeys-sec.asc

Import pub.asc into Thunderbird -> works Import subkeys-sec.asc into Thunderbird -> fails

Errors on console: [get_packet_body_s2k() /home/user/moz/comm-esr78/mozilla/comm/third_party/rnp/src/librepgp/stream-packet.cpp:583] unknown s2k specifier [stream_parse_key() /home/user/moz/comm-esr78/mozilla/comm/third_party/rnp/src/librepgp/stream-packet.cpp:2201] failed to read key protection [process_pgp_key() /home/user/moz/comm-esr78/mozilla/comm/third_party/rnp/src/librepgp/stream-key.cpp:996] failed to parse key pkt at 0

Output of pgpdump of the secret key file starts with:

Old: Secret Key Packet(tag 5)(405 bytes) Ver 4 - new Public key creation time - Thu Jul 23 18:13:55 CEST 2020 Pub alg - RSA Encrypt or Sign(pub 1) RSA n(3072 bits) - ... RSA e(17 bits) - ... Sym alg - Plaintext or unencrypted data(sym 0) GnuPG gnu-dummy (s2k 1001)

[dewyatt]

Sounds like we should bump the priority of https://github.com/rnpgp/rnp/issues/1147 up

[ni4]

@dewyatt Agree. I'll handle these, it should not be hard to parse this custom s2k. The only question is whether rnp will be okay with secret key without secret data.

[kaie]

It's not yet fully working as expected.

I can import the subkeys. (I use a temp FFI handle.)

For the primary key, rnp_key_have_secret returns true. Shouldn't it return false?

Calling rnp_key_unprotect returns RNP_ERROR_BAD_PASSWORD, that might be ideal either, I'd rather expect something like RNP_ERROR_KEY_NOT_FOUND.

[kaie]

On the console I see [decrypt_secret_key() /home/user/moz/comm-esr78/mozilla/comm/third_party/rnp/src/librepgp/stream-key.cpp:1325] No secret key data

[ni4]

@kaie Yeah, looks like we should also provide some algorithm to check whether secret key data is available, and update code for default key selection during signing (so in this case signing subkey will be used). All underlying code based on bool returns, so that's why RNP_ERROR_BAD_PASSWORD default assumption is made. Needs some time to think how to correctly update this, without breaking the other logic.

Btw, why do you need to use rnp_key_unprotect() instead of rnp_key_unlock()? First one is needed when you want to write raw secret key somewhere. To use secret key for signing/decryption is better to call rnp_key_unlock()/rnp_key_lock() once it is requested.

[kaie]

Btw, why do you need to use rnp_key_unprotect() instead of rnp_key_unlock()? First one is needed when you want to write raw secret key somewhere. To use secret key for signing/decryption is better to call rnp_key_unlock()/rnp_key_lock() once it is requested.

I currently use the following strategy for importing secret keys:

• import it into a fresh temporary FFI. This way, if anything goes wrong, we don't taint our primary key store.
• we use the temporary FFI to create a preview of the available data, show the preview to the user, and only if the user accepts we will import into the permanent space
• we don't allow individual password protection in our permanent space. All stored secret keys must use the same password. That means at import time, we must change the old password to the new password.
• We call unprotect, and export the unprotected key to memory, then we import it into the permanent space, then call protect with the new password

[ni4]

@kaie Could please check the following additions to the FFI API: https://github.com/rnpgp/rnp/pull/1248/files#diff-3acb1faab911581f76591fac05ba92fd (especially function rnp_key_get_protection_type()).

Would these be enough for you to recognize case where actual secret key data is absent?

[fuelflo]

Any news on this? As automatic update from TB68 to TB78 is coming closer, i'd be really happy to keep on using my GPG key in TB.

[ni4]

@fuelflo It is implemented on the RNP side, but not sure about the Thunderbird. Ping @kaie

[STRML]

This is broken in Thunderbird 78 unfortunately.

[ni4]

@STRML Honestly, I'm not sure whether this feature was picked by TB team already.

[STRML]

Okay. I ended up figuring out the issue - I was importing a key that contained several long-expired subkeys. After I removed those subkeys in GPG Keychain, and re-exported, the import into rnp/Thunderbird worked great.

[ni4]

@STRML Hm, that should not be an issue, at least for RNP - subkeys should be just marked as expired and unusable, but still imported.

[STRML]

The exact error was rnp_key_unprotect failed, from https://hg.mozilla.org/comm-central/file/584545287aa2757e7596bc445359e81598e13eba/mail/extensions/openpgp/content/modules/RNP.jsm#l1672. I realize this is the wrong issue tracker, so consider this for informational purposes only :)

[Aldekein]

Honestly, I'm not sure whether this feature was picked by TB team already.

I came to this thread from https://bugzilla.mozilla.org/show_bug.cgi?id=1654893 while I was exploring if Thunderbird can work with an offline primary key (generated as in this tutorial), by signing using a sub-key.

For our case the sub-keys should be stored on an OpenPGP-compatible smart cards, which I believe[ref] are also unsupported.

[kaie]

Just as an update, unfortunately the higher priorities of other TB issues hasn't allowed me to work on this yet.

[antipatico]

I came to this thread from https://bugzilla.mozilla.org/show_bug.cgi?id=1654893 while I was exploring if Thunderbird can work with an offline primary key (generated as in this tutorial), by signing using a sub-key.

Updated to version 78 today and I'm having the same issue. I also tried using the flag mail.openpgp.allow_external_gnupg and setup Thunderbid to use external GPG, but without luck.

antipatico@box:~$ thunderbird --version
 Thunderbird 78.4.3

EDIT:

I just noticed this is completely off-topic, due to being under the RNP repo and not the Thunderbird one. Anyway I will leave it here since it may be useful with people incurring in the same problem.

After starting thunderbird for the third time, I actually got the Enigmail migration popup. It actually worked, and it presumably did this:

1. set mail.opengpg.allow_external_gnupg to true
2. add an external GPG key, having the --keyid-format 0xlong, stripping the initial 0x

Now it seems like working, I hope it will help someone. Sorry for the off-topic.

[ni4]

Closing this as it implemented for a while, and needs to look nice in the 0.14 milestone. @kaie Feel free to reopen this or create an another issue.

[xpseudonym]

This bug seems it might describe my scenario, described here: https://wiki.debian.org/Subkeys?action=show&redirect=subkeys However, if it does, it's not fixed in Tb 78.7.0 (64-bit), see screenshot. $ thunderbird --version Thunderbird 78.7.0 As suggested above. $ uname -a Linux mymachine 4.19.0-14-amd64 #1 SMP Debian 4.19.171-2 (2021-01-30) x86_64 GNU/Linux

See also: https://bugzilla.mozilla.org/show_bug.cgi?id=1654893#c10 I've posted here in order to attach the screenshot which Tb bugzilla doesn't seem to provide for.