1689938 - GPG: Import of Subkeys with removed master key does not work (although it did work with enigmail)

Status: UNCONFIRMED

(MailNews Core :: Security: OpenPGP, defect)

Description

[Erpq]

Attachment: full.asc

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:83.0) Gecko/20100101 Firefox/83.0

Steps to reproduce:

-> Download + install current beta version (did not work with earlier debian version as well, though)
-> Create new PGP Key following https://keyring.debian.org/creating-key.html
-> Create Subkeys following https://wiki.debian.org/Subkeys
-> Importing PGP-Key works
-> removing master key, following second part of https://wiki.debian.org/Subkeys
-> trying to import again, does not work

Actual results:

when importing the key there is a point where the key's password is asked. regardless wether garbage or the correct password is entered, the password will be asked again and again and again and ...

The problem seems to happen also when importing from enigmail (though at this time almost all users will probably already have migrated, so it doesn't matter any more), I previously had both the private (sub) keys + the public keys in Enigmail, after importing from Enigmail only the public keys were in the key directory.

The problem also occurs in Thunderbird 78.6.0 (from debian repos) where there is the option at Account Settings > End-to-End Encryption > Add key > Use your external key through GnuPg (e.g. from a smartcard) wher the key can be added without problem but throws an error when trying to encrypt an e-mail via it.

Expected results:

The key shoul have been imported after the first time entering the correct password

In scenario 2 (Enigmail) the private key should have been imported when the keys were imported

In scenario 3 (gnupg) the encryption should have succeeded.

Attached you can find two versions of a demo pgp key, password is test
one is with, one is without removed master key
Note: only one file can be attached, I will try to attach the second file in a comment later - otherwise the attaced file is the full key with already generated subkeys but still not removed master key

Comment 1

[Erpq]

Attachment: subkeyOnly.asc

contains only subkeys, truncated/removed master key

Comment 2

[Nickolay Olshevsky]

There were some discussion on this issue on our issue tracker: https://github.com/rnpgp/rnp/issues/1217
Basically, it is implemented on RNP's side since September, 2020, but didn't get to the Thunderbird yet.

Comment 3

[Kai Engert [:KaiE:]]

Sounds like duplicate of bug 1654893

Comment 4

[onkobu]

This issue still (78.10.1 (64-Bit)) persists and it is annoying. There is no need for the private master key since only the subkeys are used per key feature (sign, encrypt). It is a security concern to copy keys around, esp. the master key.

1. Create any key with GPG2, e.g. an RSA 2048 holding 2 subkeys, one to sign, the other to encrypt mails.
2. Export the entire key structure (master+sub keys) as all_keys.sec
3. Delete the master key
4. Export the remaining key structure (sub keys only) as sub_keys.sec
5. import sub_keys.sec into Thunderbird (Account options -> End 2 End Encryption -> Manage Keys -> Import Secret Key From File)
6. Cancel 5, retry with all_keys.sec

#5 goes into an endless loop requesting the password, I also assume, that Thunderbird cannot deal with non-master keys correctly. It displays an info message about technical issues when verifying (my own) signatures.

For those who fear to read through the gpg2 manual to get the commands right:

Regarding #1:

• create a file doe.batch
• fill it with:
  %echo Generating a default key
  Key-Type: RSA
  Key-Length: 2048
  Subkey-Type: RSA
  Subkey-Length: 2048
  Subkey-Usage: encrypt
  Name-Real: Joe Tester
  Name-Comment: with stupid passphrase
  Name-Email: [e-mail]
  Expire-Date: 0
  Passphrase: abc

Do a commit here, so that we can later print "done" :-)

%commit
%echo done

• run: gpg2 --gen-key --batch doe.batch

Regarding #2:

• gpg2 --list-secret-keys --with-keygrip
• find the keys for [e-mail]
• gpg2 --export-secret-keys <key-id> >all_keys.sec, whereas <key-id> must be replaced with the last 8 digits from list-secret-keys omitting any space between the 4-char-groups

Regarding #3:

• gpg-connect-agent "DELETE_KEY <key-grip>" /bye, whereas <key-grip> is the keygrip value from the previous list-secret-keys, the whole number/char sequence

Regrading #4:

• gpg2 --export-secret-keys <key-id> >sub_keys.sec, same as for #2, except the file to spool it to is now different (and lacks the master key, too)

General questions:

• is it necessary to add --armor: seems not, works the same way with binary output as well as ASCII-armored
• does it work with gpg, too: partially, gpg does not support deleting (master keys) through gpg-connect-agent
• was it an avoidable mistake: Key management is hard, requires expertise as well as experience, so: maybe/ depends
• can this be tested automatically: see the sequence of commands, with basic shell scripting absolutely yes
• why is there no second sub key in the batch file: neither gpg nor gpg2 support multiple sub keys in batch operations, ref. https://www.gnupg.org/documentation/manuals/gnupg/Unattended-GPG-key-generation.html

Comment 5

[onkobu]

(In reply to Kai Engert (:KaiE:) from comment #3)

Sounds like duplicate of bug 1654893

Read through bug 1654893 and can confirm: duplicate.

Comment 6

[Nickolay Olshevsky]

Maybe I'm missing something, but https://bugzilla.mozilla.org/show_bug.cgi?id=1654893 seems to be about keys, exported via gpg --export-secret-subkeys, which produces some stub instead of the primary secret key. But here you seem to completely delete the secret key, attempting to import subkeys only?

Comment 7

[onkobu]

The introduction of bug reads 1654893

Expert users might want to use a configuration, which uses a primary key that is in secure offline storage. They would then use multiple subkeys, at least two, one for signing and one for encryption. […] They would need to import all public keys, but would import only the secret keys of the subkeys into Thunderbird.

This does not explicitly name commands/ strategies how to achieve »import[ing] only secret keys«. You're absolutely right, --export-secret-subkeys is one approach leaving the master key out of the export but still in the key structure. I use the more general term key structure in favor of key ring since private keys are not stored in a/the key ring.

That is why I wrote down the set of commands how to achieve a primary key that is in secure offline storage, that is gpg2 --list-secret-keys renders the master key with prefix sec# to illustrate absent master key.

I'm certain this worked for me even after migrating from Enigmail. These days I was unable to update the key in Thunderbird after extending validity (of the sub keys with a temporarily added master key). In addition some recipients of my mails complained about a bug-icon with an exclamation mark – which I verified by sending a signed mail to a second account of the same Thunderbird instance.

Encryption, signing and decryption worked fine. Only updating/ re-importing the secret keys failed with an endless loop when entering the password (to unlock the keys). Right now I'm in the process of updating Thunderbird to 78.10.2 to verify the fix.

Comment 8

[onkobu]

...and it works right away, with master key absent.

In addition I double checked https://wiki.debian.org/Subkeys mentioned in this bug. This is the same approach (using the same commands) that I described. (Deleting the master key based on the key grip from the agent/ secret key store.)

I also apologize for the mixture of master- and primary key. They describe the same thing.

Comment 9

[onkobu]

And I also checked the attached files (gpg2 --import --import-options full.asc) they both contain no master key (first line starts with sec# instead of only sec) and also no subkeys. There are only two uids:

sec# rsa4096/0x74631F9D3C1A2C78 2021-02-01 [SC] [expired: 2021-02-11]
Key fingerprint = F20E 0145 E673 CC9B CF7D F90A 7463 1F9D 3C1A 2C78
uid Test1 TestTest1 (Obviously jus a test) <[e-mail]>
uid Test1 TestTest1 (Meow!) <[e-mail]>

sec# rsa4096/0x74631F9D3C1A2C78 2021-02-01 [SC] [expired: 2021-02-11]
Key fingerprint = F20E 0145 E673 CC9B CF7D F90A 7463 1F9D 3C1A 2C78
uid Test1 TestTest1 (Obviously jus a test) <[e-mail]>
uid Test1 TestTest1 (Meow!) <[e-mail]>

There ought to be one or more lines starting with ssb and assigning functions to the subkey(s), e.g. [E] for encryption or [S] for signing. It ought to look like this instead:

sec# rsa2048/0xA48001BD9F32A971 2013-07-17 [SC]
Key fingerprint = ABCD 1234 ... 0987
uid Test1...
uid Test1 (Meow!)...
ssb rsa2048/0xCBF6... 2015-06-22 [E] [expires: ...]
ssb rsa2048/0x33... 2016-04-27 [S] [expires: ...]

And again to clarify my point: as soon as the master key is deleted and the resulting secret key file shows sec# as first chars Thunderbird pre 78.10.2 looped in password prompt. Now with 78.10.2 it doesn't anymore. Also before 78.10.2 there was no loop as soon as the master key re-appeared in the exported key file (first chars sec, without #).

A small note regarding .asc: it is common practice to only use .asc if --armor was added as option, thus ASCII armored output is created. (text file containing dashes with BEGIN and END sections and base64 in between.) Both attachements are binary key files lacking --armor (but are perfectly usable with gpg2 without any conversion).

Comment 10

[onkobu]

small typo and lack of editing: gpg2 --import --import-options show-only full.asc – show-only is necessary with --import-options. (Does not import the keys.)

Comment 11

[Kai Engert [:KaiE:]]

Does this mean 78.10.2 works for everyone, and this can be closed, marked as a duplicated of bug 1654893 ?
Does it work with the scenario that Erpq has described?

Comment 12

[onkobu]

I even found out why it worked on most of my instances/ profiles: https://wiki.mozilla.org/Thunderbird:OpenPGP:Smartcards. It is possible to use external GPG (without a smartcard). The referenced key can be without master key without issues. And without the need to import anything. (But requires unlocking the feature through about:config.)

Comment 13

[Kai Engert [:KaiE:]]

My question (does importing work with 78.10.2 ?) refers to the default configuration.

(onkobu, if you are using external gnupg, then your experience is unrelated to this report.)