openpgp: invalid data: user ID signature with wrong type

[DamienCassou]

Whatever I try I always get:

$ go run main.go 
2024/03/27 22:09:05 Enter path to private PGP key (default: ./priv.asc):
./damien.asc
2024/03/27 22:09:09 openpgp: invalid data: user ID signature with wrong type

This is with the latest version of golang installed on a fresh debian system in a VM.

I generated the ./damien.asc file with:

$ gpg --export-secret-keys --armor F72C652AE7564ECC 

F72C652AE7564ECC is my main key id (not a subkey).

The ./damien.asc file is 81 lines long (compared to the 26 lines of the test-key.asc in the repository). Is the size normal? The file looks like:

-----BEGIN PGP PRIVATE KEY BLOCK-----
...
-----END PGP PRIVATE KEY BLOCK-----

[pinpox]

Could you add the output of gpg -K? Would be interesting to see the key structure.

[DamienCassou]

sec#  ed25519/0xF72C652AE7564ECC 2018-07-09 [C] [expires: 2027-12-21]
      Key fingerprint = 8E64 FBE5 45A3 94F5 D35C  D202 F72C 652A E756 4ECC
      Keygrip = 35A4020C4AFC2279CEE0BC36E2CEE4EFA8C6CFD5
uid                   [ultimate] Damien Cassou <[email protected]>
uid                   [ultimate] Damien Cassou <[email protected]>
uid                   [ultimate] Damien Cassou <[email protected]>
ssb>  ed25519/0xB68746238E59B548 2018-07-09 [S] [expires: 2026-01-02]
      Keygrip = C89E5AABCBF7142DBC26E68FB3121DE12DCBF4FF
ssb>  cv25519/0x65CD5E0200C56C17 2018-07-09 [E] [expires: 2026-01-02]
      Keygrip = 867EA9F6ADBEBE18ED98253B884F53CBD53C526B
ssb>  ed25519/0xF36CF32DF9B09855 2018-07-09 [A] [expires: 2026-01-02]
      Keygrip = 553D56865642B05AB3C5B62DC68795691702B960

[pinpox]

The # and > at the beginning of the lines indicate that this is a stub key, meaning you don't have they available. Maybe it is on a card or imported incorrectly. See the info at the bottom here: https://wiki.debian.org/GnuPG/StubKeys

The # indicates that the private key for that key is not available at all. This is the case with off-line master keys.

The > indicates that the private key is only a stub, meaning that it's not actually stored on the computer but that one needs the right smartcard/dongle to access it. As the stub encodes the serial number GnuPG will ask you to insert the device with that serial number when one attempts to perform any operation that requires the private key for which only a stub exists and the corresponding device is not plugged in at that time.

[DamienCassou]

Yes. When I extracted the output above, I was online and when I'm online my private key is not accessible. Here is the result of the same command while my private key is available:

sec   ed25519/0xF72C652AE7564ECC 2018-07-09 [C] [expires: 2027-12-21]
      Key fingerprint = 8E64 FBE5 45A3 94F5 D35C  D202 F72C 652A E756 4ECC
      Keygrip = 35A4020C4AFC2279CEE0BC36E2CEE4EFA8C6CFD5
uid                   [ultimate] Damien Cassou <[email protected]>
uid                   [ultimate] Damien Cassou <[email protected]>
uid                   [ultimate] Damien Cassou <[email protected]>
ssb>  ed25519/0xB68746238E59B548 2018-07-09 [S] [expires: 2026-01-02]
      Keygrip = C89E5AABCBF7142DBC26E68FB3121DE12DCBF4FF
ssb>  cv25519/0x65CD5E0200C56C17 2018-07-09 [E] [expires: 2026-01-02]
      Keygrip = 867EA9F6ADBEBE18ED98253B884F53CBD53C526B
ssb>  ed25519/0xF36CF32DF9B09855 2018-07-09 [A] [expires: 2026-01-02]
      Keygrip = 553D56865642B05AB3C5B62DC68795691702B960

[pinpox]

I'm not sure, but mine does not have the > either.

[DamienCassou]

Just to be clear: I tried pgp2ssh with my private key available (I had to type the passphrase to get gpg to export the private keys).

[Kulbartsch]

pgp2ssh tries to extracts your authentication key [A], but this does not work, because it is on the smartcard/some-usb-token as indicated by the ">". In your export is only a reference to the smartcard.

If you want it to do some shh login try using the gpg-agent. It can replace the ssh-agent and works without hassle with your smartcard. See 'man gpg-agent'.

[pinpox]

pgp2ssh tries to extracts your authentication key [A], but this does not work, because it is on the smartcard/some-usb-token as indicated by the ">". In your export is only a reference to the smartcard.

Correct. That's what I liked above

If you want it to do some shh login try using the gpg-agent. It can replace the ssh-agent and works without hassle with your smartcard. See 'man gpg-agent'.

That will work for login, but not to get a ssh key as file, which is what they are trying to do. Either way, If you have a backup you can try to re-import it correctly to a new, empty .gnupg and see if you have the subkeys. if you don't have the keys, there is not much we can do I'm afraid.

[DamienCassou]

I started a discussion on gnupg-users mailing list and got some answers: https://lists.gnupg.org/pipermail/gnupg-users/2024-March/067023.html.

[pinpox]

Thanks for sharing! Sadly it confirmes what I thought and without any proper backup of the key you won't be able to extract a private SSH key to my knoledge. The last reply of that thread is by Werner, I assume it is the same person that worked on the export functionality mentioned in the README.md https://dev.gnupg.org/T6647

Since this is not really something I can help, I think we can close the issue. Feel free to reopen or comment if there are any new developments, maybe you do manage to find a backup of that key somewhere

[liby]

I have the same issue. Here's a brief overview of my process:

1. Backup Method: I used the command gpg --armor --export-secret-keys --export-options backup -o /path/to/save/backup.gpg <key-id> to create a backup of my keys. This method was supposed to backup both my primary key and subkeys, including both the private and public components as well as GnuPG-specific data.

2. Restoration Method: To restore from the backup, I used gpg --import-options restore --import /path/to/backup.gpg.

3. Outcome: The primary key was successfully imported back into my keyring without any issues. However, I've encountered a problem where my subkeys do not seem to be restored along with the primary key.

Here are some additional details:

• The primary key gets recognized and imported with the message indicating it's unchanged (as it was already present), which is expected. However, there's no indication that the subkeys are being processed or imported.

   ❯ gpg --import-options restore --import ./backup.gpg
   gpg: key EEEEEEEEEEEEEEEE: "Example <[email protected]>" not changed
   gpg: warning: lower 3 bits of the secret key are not cleared
   gpg: key EEEEEEEEEEEEEEEE: secret key imported
   gpg: Total number processed: 1
   gpg:              unchanged: 1
   gpg:       secret keys read: 1
   gpg:  secret keys unchanged: 1
  

• Using gpg --list-keys and gpg --list-secret-keys post-import shows the primary key but not the subkeys.

   ❯ gpg --list-secret-keys
   /Users/user/.gnupg/pubring.kbx
   -------------------------------
   sec   ed25519 2023-01-10 [C]
         EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
   uid           [ultimate] Example <[email protected]>
   ssb>  ed25519 2023-02-15 [S] [expires: 2029-01-02]
   ssb>  cv25519 2023-02-15 [E] [expires: 2029-01-02]
   ssb>  ed25519 2023-02-15 [A] [expires: 2029-01-02]
  

I've verified the backup file contains the subkeys using gpg --list-packets, so they should be part of the backup.

[pinpox]

@liby Looks like you have the same problem as discussed at https://lists.gnupg.org/pipermail/gnupg-users/2024-March/067023.html.

In any case, as long as you see the > we can't really help you here, because it is a gpg related problem. Something with the export or import might have gone wrong, if the subkeys are not available.

[DamienCassou]

@liby I was just like you, thinking that my private subkeys weren't imported but they were. My subkeys were expired and invisible: using show-unusable-subkeys made them appear. The rest worked fine.

[liby]

@liby I was just like you, thinking that my private subkeys weren't imported but they were. My subkeys were expired and invisible: using show-unusable-subkeys made them appear. The rest worked fine.

I remembered that my subkeys did expire in January and February of this year, and I renewed them for 29 years. In this case, will I be unable to retrieve them?

But I remember that after extending the validity period, I re-ran A to export them, now I am not very sure about it.

❯ gpg --list-options show-unusable-subkeys --list-keys EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
pub   ed25519 2023-01-10 [C]
      EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
uid           [ultimate] Example <[email protected]>
sub   ed25519 2023-02-15 [S] [expires: 2029-01-02]
sub   cv25519 2023-02-15 [E] [expires: 2029-01-02]
sub   ed25519 2023-02-15 [A] [expires: 2029-01-02]

[DamienCassou]

In this case, will I be unable to retrieve them?

my keys were also expired and this is no problem. You can still import them back into your keyring and export them for pgp2ssh.

[liby]

You can still import them back into your keyring and export them for pgp2ssh.

Thank you, but when I run the gpg --import-options restore --import ./backup.gpg import and then run the gpg --list-secret-keys command, I still see the > symbol after the subkeys.

[DamienCassou]

Try passing --list-options show-unusable-subkeys with --list-secret-keys to see if your keys are there.

[liby]

Try passing --list-options show-unusable-subkeys with --list-secret-keys to see if your keys are there.

Thank you very much. After running the rm -rf ~/.gnupg command, I re-imported and ran gpg --list-secret-keys --list-options show-unusable-subkeys --with-keygrip again to see all the keys, and the following steps went very smoothly.