Cant login: openpgp: unsupported feature: public key type: 22

[rdlu]

I've created my keys using gpg based on this guide: https://alexcabal.com/creating-the-perfect-gpg-keypair/

But I choose the ed25519 curve as master key algorithm instead of rsa. So I have this keys layout:

sec#  ed25519/195065AA 2015-12-09 [expires: 2025-12-06]
uid         [ultimate] Rodrigo Dlugokenski <r@dlu.io>
uid         [ultimate] Rodrigo Dlugokenski <rodrigodlu@outlook.com>
uid         [ultimate] Rodrigo Dlugokenski <r.dlu@outlook.com>
uid         [ultimate] Rodrigo Dlugokenski <rdlu.io@gmail.com>
ssb   rsa4096/067BAD42 2015-12-09 [expires: 2023-12-07]
ssb   rsa4096/25290539 2015-12-09 [expires: 2023-12-07]

When I try to login from my ArchLinux machine, I got this error:

[ERRO keybase main.go:47] 06c openpgp: unsupported feature: public key type: 22

Any advice, or this is really a bug/unsupported algorithm? Do I really need to choose RSA as master key algorithm?

$ keybase -version
keybase version 1.0.5-6
$ gpg --version
gpg (GnuPG) 2.1.9

[maxtaco]

This is sadly a limitation of Go's PGP implementation. We'll fix it when we get a moment.

For your own benefit, while Ed25519 is a better signature algorithms than ECDSA or DSA, you still want people to be able to verify your signatures who have old software, and a preponderance of PGP users still use 2.0 or 1.4 and therefore cannot.

[rdlu]

So I can wait about Go PGP, as a developer I know it takes time.

But about the second part, an odd question:

Why do I need to care about old software? Respectfully, lets see some cases: IE6,7 -> Firefox, later Chrome Ruby 1.8 -> Ruby 1.9,2.0 Kernel 2.6.32 -> Kernel 3+ Flash->HTML5+CSS3 Win95,98->2000,XP SVN->GIT

These cases showed me in the last two decades that if i don't have a strong case (like "will starve if I don't use"), we must push forward, including people close to us.

It took one year to compel my colleagues changing SVN to GIT years ago, but today my boss is thankful I did sooner.

Since I'm relatively new to using pgp on daily basis, this is a question that I havent found a answer upon creating my keys, searching google, pgp comunities, etc. So I just ignored the old versions.

Theres a strong case about using 1.4? I dont think "embeded uses" stays in the 90th percentile. Mobile versions already supports 2.1 set. Now about 2.0: maybe, since these type of tools people in MacOS X and Windows always get late on the party, even with alternatives already in place (both have installers with 2.1 version).

I will switch to an older key algorithm, and try to cross sign them. But the question stays. Thanks for understanding, since no one answered that properly.

And oh, thanks for this amazing service that keybase is. Maybe it will sparkle more of these questions and people really start to care about security, specially bringing them closer to average people.

[rdlu]

I've created a keypair with 4096RSA for sign and 2048RSA for encrypt, reseted my keybase identity, etc.

And yet I got the error, even explicitly selecting the correct key (don't wanna to delete the ED25519 key).

I really need to delete the other key from my system? Tried 3 and 4 options, same error.

$ keybase login
How would you like to sign this install of Keybase?

(1) Use an existing device
(2) Use a paper key
(3) Use my Keybase passphrase
(4) Use GPG
Choose a signing option: 4
In order to authorize this installation, keybase needs to sign this installation
with your GPG secret key.

You have two options.

(1) Keybase can use GPG commands to sign the installation.

(2) Keybase can export your secret key from GPG and save it to keybase's local encrypted
    keyring. This way, it can be used in 'keybase pgp sign' and 'keybase pgp decrypt' 
    going forward.
Which do you prefer?: 2
#    Algo   Key Id             Created      UserId
=    ====   ======             =======      ======
1    ?      DAC8D864195065AA   2015-12-09   Rodrigo Dlugokenski <r@dlu.io>, Rodrigo Dlugokenski <rodrigodlu@outlook.com>, Rodrigo Dlugokenski <r.dlu@outlook.com>, Rodrigo Dlugokenski <rdlu.io@gmail.com>
2    R      02D8ECE253F0D674   2015-12-10   Rodrigo Dlugokenski <rddweb@gmail.com>
Choose a key: 2
▶ ERROR openpgp: unsupported feature: public key type: 22

[rdlu]

Now I deleted the keys, including public keys with ECDSA from other people. Restarted my system, etc.

Same error :(

[rdlu]

Ok, now I'm nuts. Deleted the entire .gnupg dir, rebooted my computer, reseted my keybase account, created the key using the web wizard and SAME error :(

Log: https://gist.github.com/rdlu/a4b8f3f0f968c9db819c

Installed keybase in ArchLinux, using yaourt.

$ gpg --version
gpg (GnuPG) 2.1.9
libgcrypt 1.6.4
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

[maxtaco]

Sorry about this issue. There is clearly a bug some sort on our side. We will take a look today.

On Thursday, December 10, 2015, Rodrigo Dlugokenski < notifications@github.com> wrote:

Ok, now I'm nuts. Deleted the entire .gnupg dir, rebooted my computer and SAME error :(

Log: https://gist.github.com/rdlu/a4b8f3f0f968c9db819c

— Reply to this email directly or view it on GitHub https://github.com/keybase/keybase-issues/issues/1910#issuecomment-163628722 .

[maxtaco]

To help us out, can you run keybase -d login and paste that trace? If you don't feel comfortable posting it here (it's all public data), you can encrypt it to me at max@keybase.io.

Also, what's the full output of gpg -K --with-fingerprint?

[rdlu]

The last log is in gist: https://gist.github.com/rdlu/a4b8f3f0f968c9db819c

I tried a lot of gpg key combinations. My last gpg -K state:

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   2  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 2u
gpg: next trustdb check due at 2017-12-09
/home/rodrigo/.gnupg/pubring.kbx
--------------------------------
sec   rsa4096/53F0D674 2015-12-10 [expires: 2017-12-09]
      Key fingerprint = 5EE7 36BB 2BA3 BBC7 879A  5BF8 02D8 ECE2 53F0 D674
uid         [ultimate] keybase.io/rdlu <rdlu@keybase.io>
uid         [ultimate] Rodrigo Dlugokenski (gpg-legacy-key) <rddweb@gmail.com>
uid         [ultimate] Rodrigo Dlugokenski (keybase-1) <rdlu@keybase.io>
ssb   rsa2048/2D966393 2015-12-10 [expires: 2017-12-09]

sec   ed25519/195065AA 2015-12-09 [expires: 2025-12-06]
      Key fingerprint = 7800 45C2 A4FC 26C2 C01C  8003 DAC8 D864 1950 65AA
uid         [ unknown] Rodrigo Dlugokenski <r@dlu.io>
uid         [ unknown] Rodrigo Dlugokenski <rodrigodlu@outlook.com>
uid         [ unknown] Rodrigo Dlugokenski <r.dlu@outlook.com>
uid         [ unknown] Rodrigo Dlugokenski <rdlu.io@gmail.com>
uid         [ unknown] Rodrigo Dlugokenski (keybase-eddsa) <rdlu@keybase.io>
ssb   rsa4096/067BAD42 2015-12-09 [expires: 2023-12-07]
ssb   rsa4096/25290539 2015-12-09 [expires: 2023-12-07]

I've got rid of keybase GO from AUR and installed from community (nodejs 0.8.25)

It worked fine, without hitch (it complained about eldest key, uploaded through web interface).

$ keybase status
{
  "status": {
    "configured": true,
    "logged_in": false
  },
  "user": {
    "name": "rdlu",
    "key": {
      "key_id": "DAC8D864195065AA",
      "fingerprint": "7800 45C2 A4FC 26C2 C01C 8003 DAC8 D864 1950 65AA"
    }
  }
}
$ keybase version
keybase (keybase.io CLI) v0.8.25
- node.js v5.2.0
- gpg (GnuPG) 2.1.9
- libgcrypt 1.6.4
Identifies as: 'keybase.io node.js client v0.8.25 linux'

Maybe this shows that is something on Go based version.

[maxtaco]

@oconnor663 figured out the issue, which is that your Public key on the keybase server is EdDSA, which the Go client doesn't support. So it didn't matter what your local keyring said, it was the server's key that was the problem.

[rdlu]

Hmm it makes sense after I realized you store my old keys (eldest key error). It's in my key history indeed.

Maybe theres a way to ignore until you implement in GO version?

[oconnor663]

@rdlu if you want to be able to use the Go client without waiting for Ed25519 support, the easiest thing is probably just to do another account reset using the website. You can then either upload an RSA PGP key, or just log in immediately with the Go client, which will create a NaCl Ed25519 key for you (and then let you add PGP keys if you want).

[rdlu]

@oconnor663 I reseted like 5 times this morning, tried to generate "cleanly" through wizard (web and go-client, with local gnupg wiped). I think the error is caused ALSO because of the key history you stores, go-client tries to recognize somehow and fails.

[oconnor663]

Hmm, that's surprising to me. Could you give me the exact steps you use to try to log in, and the public key you're using? Like:

1) "Reset my keys and start from scratch" using the website. 2) ...

[oconnor663]

Ah, @maxtaco has reminded me that we might be trying to verify old links of yours from before the account reset. I'm trying to repro now.

[rdlu]

Ok, new try:

1) sudo pacman -R keybase (nodejs version removal) 2) rm -rf .config/keybase 3) rm -rf .gnupg/ 4) gpg --list-keys (recreating .gnupg dir, checking if some left) 5) yaourt -S keybase-release (installing go version) 6) Reset in web interface 7) keybase -d login

Same error.

Gist with log: https://gist.github.com/rdlu/b398e9961037993aac2a

[maxtaco]

We're convinced. We need to fix this. We'll get back to you shortly. I'm going to fast-track EdDSA implementation. Thanks for your feedback and patience!

[rdlu]

Not a problem! You're welcome! I will use nodejs for now, and enforce the interested people to use while you work out. Take your time, it's alpha after all :+1:

[oconnor663]

Yeah this is a great catch, thanks for the report.

[007]

@maxtaco are Ed25519 keys supported in keybase yet? I got unsupported oid instead of public key type: 22, but otherwise the error looks the same, and the result as well.

[maxtaco]

yeah that should be

cc @zapu maybe he has another idea

also do a keybase log send so we can see what happened

[007]

Log ID f1145e641a8ad8617127821c

Seems to be #2506 which also isn't closed.