Error trying to select an existing key

[alex]

This is likely caused because it's a key on a hardware device (Yubikey NEO):

~ $ keybase pgp select
#    Algo    Key Id             Created   UserId
=    ====    ======             =======   ======
1    4096R   125F5C67DFE94084             Alexander Nathan Gaynor <[email protected]>, Alexander Nathan Gaynor <[email protected]>
2    2048R   D1B3ADC0E0238CA6             Alexander Nathan Gaynor <[email protected]>
Choose a key: 2
▶ ERROR ImportKey error: openpgp: unsupported feature: hash for S2K function: 0

[maxtaco]

Thanks for the bug report. I just fixed a bug with weird S2Ks yesterday, but this seems to be a new one. I'll take a look a little later today, thanks for your continued patience and help!

[alex]

Should have included version numbers:

~ $ keybase version
Client:  1.0.3-0
Service: 1.0.3-0

(latest that's in homebrew)

[maxtaco]

Very helpful, thanks.

[maxtaco]

Can you issue this command?

gpg  --export-secret-key D1B3ADC0E0238CA6 | gpg --list-packets | grep S2K

For me I see something like:

iter+salt S2K, algo: 9, SHA1 protection, hash: 8, salt: 6347a50031ec51ec

You can snip out the salt if you want, though it's not truly sensitive. Thanks for your help!

[alex]

    gnu-divert-to-card S2K, algo: 0, simple checksum, hash: 0
    gnu-divert-to-card S2K, algo: 0, simple checksum, hash: 0
    gnu-divert-to-card S2K, algo: 0, simple checksum, hash: 0

[maxtaco]

Super useful, thanks...

[alex]

@maxtaco let me know if there's any other info I can provide.

[maxtaco]

We've ordered some yubikeys so we'll check back in once we can understand and repro the issue. Obviously harder to debug since it's a private key and we can't ask for more data. Thanks @alex!

[alex]

haha, awesome. thanks much!

[ojkelly]

Just to add to this, it's happening to me with a Yubikey 4

$ keybase pgp select
#    Algo    Key Id             Created   UserId
=    ====    ======             =======   ======
1    4096R   4441157E939003C0             Owen Kelly <[email protected]>
Choose a key: 1
▶ ERROR ImportKey error: openpgp: unsupported feature: hash for S2K function: 0```

Running the lastest on OS X installed via brew

$ keybase -v
keybase version 1.0.7-0

To reproduce:

• generated key on airgapped computer with latest TAILS
• generated keys for ESA on Yubkikey
• published public key
• kill TAILS and switch to everyday computer
• imported public key
• connected Yubikey
• verified can decrypt and sign using gpg
• then tried keybase pgp select

[alex]

FWIW, the error message appears to have regressed:

~ $ keybase -v
keybase version 1.0.9-0
~ $ keybase pgp select
▶ ERROR EOF

Has any thought been given to bringing back the old "do a signature" method of adding a PGP key, until this issue is resolved

[maxtaco]

Shoot, likely the update failed. Can you do a keybase version?

Also, can you do a keybase id -d max?

Thanks.

cc: @gabriel

[alex]

~ $ keybase version
Client:  1.0.9-0
Service: 1.0.8-0
~ $ keybase id -d max
Incorrect Usage.

NAME:
   keybase id - Identify a user and check their signature chain

USAGE:
   keybase id [command options] [username]

DESCRIPTION:
   Identify a user and check their signature chain.  Don't specify a username to identify yourself.  You can also specify proof assertions like user@twitter.

OPTIONS:
   -t, --track-statement    Output a tracking statement (in JSON format).

Error parsing command line arguments: flag provided but not defined: -d

(My keybase comes from Homebrew, FWIW)

[maxtaco]

Whoops, sorry I meant keybase -d id max. Sorry about that. Thanks for your help.

[alex]

~ $ keybase -d id max
21:12:33.295976 ▶ [DEBU keybase json.go:50] 001 + loading config file: /Users/alex_gaynor/Library/Application Support/Keybase/config.json
21:12:33.298280 ▶ [DEBU keybase json.go:78] 002 - successfully loaded config file
21:12:33.304433 ▶ [DEBU keybase ui.go:451] 003 Setting GPG_TTY to /dev/ttys005
21:12:33.304859 ▶ [DEBU keybase globals.go:205] 004 Keybase CLI 1.0.9-0
21:12:33.304880 ▶ [DEBU keybase globals.go:205] 005 - Built with go1.5.3
21:12:33.304888 ▶ [DEBU keybase globals.go:205] 006 - Visit https://keybase.io for more details
21:12:33.304917 ▶ [DEBU keybase main.go:120] 007 + configureProcesses
21:12:33.304945 ▶ [DEBU keybase install_osx.go:479] 008 + AutoInstall for launchd
21:12:33.305920 ▶ [DEBU keybase install_osx.go:492] 009 | already installed at /Users/alex_gaynor/Library/LaunchAgents/homebrew.mxcl.keybase.plist
21:12:33.305953 ▶ [DEBU keybase install_osx.go:481] 00a - AutoInstall -> false, <nil>
21:12:33.305965 ▶ [DEBU keybase main.go:186] 00b | After forks; newProc=false
21:12:33.305978 ▶ [DEBU keybase main.go:207] 00c + configureLogging
21:12:33.307251 ▶ [DEBU keybase socket_nix.go:23] 00d Dialing unix:/Users/alex_gaynor/Library/Caches/Keybase/keybased.sock
21:12:33.328374 ▶ [DEBU keybase main.go:209] 00e - configureLogging
21:12:33.328445 ▶ [DEBU keybase main.go:122] 00f - configureProcesses -> EOF
21:12:33.432275 ▶ [DEBU keybase globals.go:250] 010 Calling shutdown first time through
21:12:33.432377 ▶ [DEBU keybase login_state.go:897] 011 + Account "LoginState - Shutdown"
21:12:33.432449 ▶ [DEBU keybase login_state.go:899] 012 - Account "LoginState - Shutdown"
21:12:33.432478 ▶ [DEBU keybase globals.go:290] 013 exiting shutdown code=0; err=<nil>
21:12:33.432504 ▶ [ERRO keybase main.go:58] 014 EOF

[maxtaco]

Thanks @alex. The other bad news is that the feature you want still isn't done. We've been working super hard on a bunch of other features that we hope to push out the door this week.

[alex]

👍

[maxtaco]

Looks like we botched the update mechanism with an non-backwards-compatible protocol change. We'll fix that bug with high priority, but in the mean time, it should work to pkill keybase and then try whatever you were doing again. Thanks @alex!!

[alex]

Confirmed that there's no more EOF error, and we're back to a boring old
S2K hash thingy :-) If there's another PR or issue to follow along with, I
can follow that :-)

On Sun, Jan 24, 2016 at 10:37 PM, Maxwell Krohn [email protected]
wrote:

Looks like we botched the update mechanism with an
non-backwards-compatible protocol change. We'll fix that bug with high
priority, but in the mean time, it should work to pkill keybase and then
try whatever you were doing again. Thanks @alex https://github.com/alex
!!

—
Reply to this email directly or view it on GitHub
#1885 (comment)
.

"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084

[pipermerriam]

Just chiming in that I'm getting the same error with a nitrokey pro based RSA key.

[ChlorideCull]

Yup, this is just any hardware device in GPG. It happens with an OpenPGP smart card as well.

[alevy]

I believe this might be an issue with the underlying golang library: golang/go#13605

[maxtaco]

@alevy we've been slowly working around these errors in our fork. It's news to me that we're not handling non-hardware keys where the primary is offline. I should look further into it. Can you paste in (or email me) a copy of your public key? Thanks!

[alevy]

@maxtaco Output of the command you asked for earlier

$ gpg  --export-secret-key 838FA1C717F60F73 | gpg --list-packets | grep S2K
        iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: 505E4AF0A0ECB4E9
        iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: C7A32F2BD624865F
        iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: 87082912A711A4F3
        iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: C759B7A6C999A81E
        gnu-dummy S2K, algo: 0, simple checksum, hash: 0
        iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: 9DC5C2578FFE383B

The public key is big, so I'll just e-mail it to you. Incidentally, this would be an amazing use of KBFS, but alas, I don't have access yet :(

[maxtaco]

I think I have an idea for a fix, but want to test it. @alevy, do you remember how you generated your key? Can you generate a new throw-away one the same way (or tell me the GPG version, platforms and steps that you used?) Thanks!

[maxtaco]

I have a PR up: keybase/go-crypto#10

My guess is this solves the issue, but I can't test it. My GPG install spits out gnu-dummy S2K with hash: 3, for whatever reason

[maxtaco]

@alevy I might have fixed your issue; changes are now in master.

[alevy]

@maxtaco awesome. Will test tomorrow.

[alex]

I set it up with the fellow who wrote these guides: https://github.com/matthewjweaver/mjw-toolbox/tree/master/crypto/yubi I give it a 50/50 that the guide matches what I ran. I'll take a whirl at this and send a PR for the "read and discard"

[maxtaco]

Cool! Thank you!

On Sunday, February 21, 2016, Alex Gaynor [email protected] wrote:

I set it up with the fellow who wrote these guides:
https://github.com/matthewjweaver/mjw-toolbox/tree/master/crypto/yubi I
give it a 50/50 that the guide matches what I ran. I'll take a whirl at
this and send a PR for the "read and discard"

—
Reply to this email directly or view it on GitHub
#1885 (comment)
.

[alex]

PR sent!

[alex]

(If there's some way I can export the relevant state for you so it's more reproducible, let me know!)

[alex]

We have a new error to contemplate:

▶ ERROR ImportKey error: openpgp: invalid data: tag byte does not have MSB set

https://github.com/keybase/go-crypto/blob/master/openpgp/packet/packet.go#L158-L169 looks to the site of the offender.

[killtheliterate]

A buddy of mine has not had this issue with a key he generated on the Yubikey. I'm not sure if that is useful/relevant. cc/ @legittalon

The primary difference I can see between his and my key is that his master key is present on the Yubikey, while mine is not, as it was generated in Tails.

[pipermerriam]

I've just updated to 1.0.14-1 and am still getting errors trying to import the key.

ERROR ImportKey error: openpgp: unsupported feature: unknown SymmetricallyEncrypted version

Key was freshly generated on a Nitro-Key-Pro

[maxtaco]

@alex we have good progress on YubiKeys, @jacobhaven will update. @pipermerriam no promises about Nitro Keys, we've never played with those.

[pipermerriam]

@ansiwen would you guys be willing to send the keybase folk a nitrokey to play with?

[ansiwen]

@pipermerriam: I'm not into the USB Nitrokeys. @jans23: what do you think, can you send them one?

[chetwisniewski]

I have the same experience and setup as @killtheliterate w/yubikey. 1.0.14-1 on Arch Linux:

[chetwisniewski@chris ~]$ keybase pgp update
[chetwisniewski@chris ~]$ keybase pgp select
#    Algo    Key Id             Created   UserId
=    ====    ======             =======   ======
1    3776R   96A9C33CEDFB6E2C             Chester Wisniewski <[email protected]>, Chester Wisniewski <[email protected]>
Choose a key: 1
▶ ERROR ImportKey error: openpgp: invalid data: subkey signature invalid: openpgp: unsupported feature: unknown SymmetricallyEncrypted version

[jans23]

@pipermerriam Yes, we can send you a Nitrokey. Please send me your address. Nitrokey Pro works out of the box with GnuPG. Do you utilize GnuPG or is it your own software?

[ansiwen]

@jans23: I think either @maxtaco or @jacobhaven needs the Nitrokey, @pipermerriam just organized it because he is interested in the solution, I guess.

[pipermerriam]

@jans23 , what @ansiwen said is correct.

I am hoping that you could coordinate with @maxtaco who is with keybase on sending them a Nitrokey so that they can get their client working with the device.

[maxtaco]

To manage expectations, we might not have enough bandwidth to accommodate all GPG hardware, since we're focusing most of our efforts these days on our FS product. Always happy to look at PRs though

[jans23]

If you integrated Yubikey's OpenPGP Card feature already it may work
with Nitrokey pretty much out of the box.

Am 23.03.2016 um 21:23 schrieb Maxwell Krohn:

To manage expectations, we might not have enough bandwidth to
accommodate all GPG hardware, since we're focusing most of our efforts
these days on our FS product. Always happy to look at PRs though

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1885 (comment)

[alex]

This appears to be resolved.

[paultag]

After googling for this error, since I was hitting it in an unrelated setup, I found this thread (again, hilariously) and have a plausable theory for this:

When GnuPG exports the secret chunks of a key, it will also export the subkey private material. This will come as wholly uninteresting to everyone involved, I'm sure.

However, the interesting part is when that subkey does not have a private component associated with it (e.g. a hardware token, or subkey that has a key on another machine), it is marked "offline".

From the GPG manpage:

       -K     List  the specified secret keys.  If no keys are specified, then
              all known secret keys are listed.  A # after  the  initial  tags
              sec  or ssb means that the secret key or subkey is currently not
              usable.  We also say that this key has been taken  offline  (for
              example,  a primary key can be taken offline by exported the key
              using the command --export-secret-subkeys).   A  >  after  these
              tags  indicate  that the key is stored on a smartcard.  See also
              --list-keys.

So, I made a key, and added a subkey with the golang.org/x/crypto/openpgp library, and discarded the subkey privatekey material (since gpg can't know if that's stored somewhere real or not), and imported that into the keyring.

I then added a new key and let it keep the key material.

$ gpg -K
sec   rsa4096 2017-12-23 [SC] [expires: 2018-12-23]
      AAC04B92503C27027E9FA3727456ABE798DA7527
uid           [ultimate] foo bar don't use me <[email protected]>
ssb#  rsa2048 2017-12-23 [S] [expires: 2017-12-24]
ssb   rsa2048 2017-12-23 [S] [expires: 2018-12-23]

And, now the interesting part of --list-packets:

[other packets that aren't germane to my point]

:secret sub key packet:
	version 4, algo 1, created 1513992502, expires 0
	pkey[0]: [2048 bits]
	pkey[1]: [17 bits]
	gnu-dummy S2K, algo: 0, simple checksum, hash: 0
	protect IV: 
	keyid: C3A17CA0B9DFF1E5

[other packets that aren't germane to my point]

:secret sub key packet:
	version 4, algo 1, created 1513993077, expires 0
	pkey[0]: [2048 bits]
	pkey[1]: [17 bits]
	iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: 87557FFC8163000E
	protect count: 65011712 (255)
	protect IV:  8e db a3 af 4e 71 11 5a e5 d7 48 97 40 e3 a6 c9
	skey[2]: [v4 protected]
	keyid: 26E9A61F6F84F502

Now, on the real subkey packet, it has an S2K packet that looks legit, and the "offline" key has a "gnu-dummy" subkey on it. Neat!

Seems like it's exporting shim (and empty) secret packets for the keys it doesn't have the private half to, which would explain why it's coming up with anyone doing stuff with Yubikeys.

This is a really wackado thing for GnuPG to do, and I'm kinda creeped out that it does this rather than just outputting the public key packet. I'm sure there's a totally plausible and mature reason to do this rather than legacy code.

I guess the behavior of /x/crypto/openpgp ought to be ignoring the gnu-dummy packets, pull the public key material out of it, and go on about your day, but it's apparently trying to validate what seems to this one humble engineer as a batshit value.

If it didn't crash there, it would for sure blow up when it tried to read the actual private key material, so maybe this is better? Who can know.

[mithrandi]

I think the point of the dummy packet is so that GnuPG can tell the difference between "we don't have this secret key" and "we're supposed to have this secret key, look for a hardware device that can sign with it for us, and potentially prompt to insert it if not found". Otherwise any time you asked to sign with any key, it would have to go rummaging for a smartcard, and then maybe pop up a confusing prompt asking you to insert something you don't necessarily even have if you picked somebody else's key.

[paultag]

@mithrandi a good answer, and it does, in fact distinguish between key packets (marked with a >) and no key (marked with a#). I was only doing missing, no keycard. I haven't looked at the difference in packets (maybe my initial comment that key cards have their serial in one of these packets isn't insane), but it does it with entirely missing keys too.

Which I still, for the record, think is whackado.

[paultag]

I pushed this error to x/crypto/openpgp last night - golang/go#23226

[maxtaco]

FWIW me made so many changes to go’s implementation that we forked it a while ago.

…

On Sat, Dec 23, 2017 at 10:35 AM Paul Tagliamonte ***@***.***> wrote: I pushed this error to x/crypto/openpgp last night - golang/go#23226 <golang/go#23226> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1885 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA05_0c8nJqjSflRTdOqsDGHl5DRjSEvks5tDR23gaJpZM4GpQcL> .