Invalid S2K type error when importing a Subkey without a primary key

[koto]

From Jason.Gu...@gmail.com on June 04, 2014 22:58:46

Steps to reproduce:

Attempt to import my secret key via Options or via "Import an OpenPGP Key" dialog box under end-to-end actions menu.

What happens?
I receive an error "Invalid S2K type" through the Chrome console or at the top of the Import an OpenPGP Key Dialog. The keys do not get imported to end-to-end as is expected.

I am able to import the public keys fine, just not the private keys.

If it helps (potentially a problem with compatibility of the keys), my keys are types 1024D and 2048g, and they were generated in 2008. They seem to work fine for encryption/decryption otherwise.

Original issue: http://code.google.com/p/end-to-end/issues/detail?id=22

[koto]

From evn@google.com on June 04, 2014 19:03:17

Thanks!

Can you follow this debugging steps please? :)

Debug instructions:

1. Please build the extension and go to chrome-extension://<extension- id>/prompt.html and try to encrypt, decrypt or import a key from there.
2. Note the error shown in red (if any)
3. Open the JavaScript console (Tools -> JavaScript Console)
4. Copy the output from the console here.

Have you tested if this key/message works in other implementations? (PGP Desktop, GnuPG, etc..)

If you can, please copy the output of gpg --list-packets .

[koto]

From Jason.Gu...@gmail.com on June 04, 2014 20:32:17

The error displayed in red is "Invalid S2K Type".

Here is the output from the JavaScript console. I didn't fully expand the error, let me know if you want me to do that (or if there is a better way to grab the entire console output).

e2e.openpgp.error.ParseError message: "Invalid S2K type." stack: (...) get stack: function () { [native code] } set stack: function () { [native code] } proto: c prompt_binary.js:2227 e2e.ext.utils.errorHandler prompt_binary.js:2227

The key works on (and was generated using) GPG (can encrypt/decrypt files fine).

[koto]

From Jason.Gu...@gmail.com on June 04, 2014 21:06:32

Well, I just realized that the key I was trying to import is a subkey and not the master key. Perhaps this is the root of the issue?

[koto]

From evn@google.com on June 04, 2014 22:34:12

Thanks!

Perhaps.. but I think the error would be different.

could you click on the "(...)" after stack? It will show you the full stack trace.

What version of GPG do you use? I noticed in some cases they fail to export secret key material (in the version they have in trunk), maybe that's it.

[koto]

From Jason.Gu...@gmail.com on June 05, 2014 08:17:12

My version of GPG is 1.4.16.

I tried importing my main private key (instead of th subkey), and was successfully imported.

Here is the expanded error.

e2e.openpgp.error.ParseError {message: "Invalid S2K type.", stack: (...), constructor: function, name: "CustomError"} message: "Invalid S2K type." stack: (...) get stack: function () { [native code] } arguments: null caller: null length: 0 name: "" prototype: Object proto: function Empty() {}

set stack: function () { [native code] } arguments: null caller: null length: 1 name: "" prototype: Object **proto**: function Empty() {} **proto**: c constructor: function (a){e2e.openpgp.error.Error.call(this,a)} **proto**: c prompt_binary.js:2227 e2e.ext.utils.errorHandler prompt_binary.js:2227 e2e.ext.ui.Prompt.displayFailure_ prompt_binary.js:2508 e2e.ext.ui.Prompt.runWrappedProcessor_ prompt_binary.js:2507 e2e.ext.ui.Prompt.executeAction_ prompt_binary.js:2505 (anonymous function) prompt_binary.js:17 goog.events.fireListener prompt_binary.js:530 goog.events.handleBrowserEvent_ prompt_binary.js:533 (anonymous function)

[koto]

From evn@google.com on June 05, 2014 13:04:40

Interesting. We'll try to export an encrypted secret subkey on GnuPG 1.4.6 to try and repro.

Thanks Jason!

Status: Accepted

[koto]

From evn@google.com on June 06, 2014 18:57:14

Labels: Type-Defect Priority-Medium Component-Logic Compatibility

[koto]

From jyass...@google.com on June 12, 2014 10:35:08

I'm having a similar problem after following the instructions at https://wiki.debian.org/Subkeys to try to import only subkeys into the browser extension. I've attached the packets from the file that doesn't work. The manpage does warn that "The second form of the command has the special property to render the secret part of the primary key useless; this is a GNU extension to OpenPGP and other implementations can not be expected to successfully import such a key."

$ gpg --version gpg (GnuPG) 2.0.22 libgcrypt 1.6.1

Attachment: browser.asc.packets

[koto]

From evn@google.com on June 12, 2014 13:12:03

I see, I think it makes sense for existing PGP users to just import subkeys to the extension.

Labels: -Type-Defect Type-Enhancement

[koto]

From evn@google.com on June 16, 2014 03:45:21

Summary: Invalid S2K type error when importing a Subkey without a primary key (was: Invalid S2K type)

[koto]

From kbsriram on June 17, 2014 10:11:07

Some notes for when this enhancement is being considered/worked on :-)

The situation is: reading secret keys generated by GnuPG, when the primary secretkey packet uses the GnuPG dummy-s2k extension.

The public half of the primary key is still present as usual, only the private half is unavailable.

The public part is still necessary to verify subkey certifications or signatures, so it would be great to read and store the public half of the primary key rather than skip it entirely.

The dummy-s2k extension itself is small and simple:

The type is 101, and it consists of just 4 bytes. 'G', 'N', 'U' and a one byte "mode" - 0x01 or 0x02.

0x01 means the private key is removed, 0x02 means the private key is stored on a smartcard.

Details are at < http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/DETAILS;h=fe55ae16ab4e26d8356dc574c9e8bc935e71aef1;hb=23191d7851eae2217ecdac6484349849a24fd94a#l1109 >

Just for convenience, attached is a typical secret key that's exported with such an extension -- the password is "test"

Also attached is a small demo patch for s2k.js that parses such keys. (I fully appreciate the harder part of the enhancement is in correctly using/storing such keys rather than the parsing, so just hope even a little thing like this helps!)

Attachment: subkeys-only.gpg.asc gpg-dummy-s2k.patch

[koto]

From evn@google.com on June 21, 2014 10:05:15

Thanks KB!

Unfortunately that apparently means that we won't have the secret key material, right?

So users won't be able to use exported subkeys.

[koto]

From kbsriram on June 21, 2014 14:30:36

The secret key material for the subkeys should still be available -- only the private-key portion of the primary key is removed. The various binding signatures on the uid and subkeys can be verified with the public portion of the primary key, and then the secret material in subkeys can be used as usual for signing or decryption, based on their usage flags.

(With many apologies if this is already clear :-) - fwiw, the expected use-case is to let apps continue to sign/decrypt as usual with such an exported secret keyring. However, should this keyring be compromised, users can revoke just the subkeys alone. This is far preferable to having to revoke the primary key (as the latter effectively means a new fingerprint has to be manually re-authenticated with everyone.) Revoking subkeys - assuming regularly updated key imports - can be handled programatically.

[koto]

From evn@google.com on July 21, 2014 17:19:28

Owner: jo...@google.com

[koto]

From evn@google.com on August 11, 2014 21:30:15

Hey Josh

Your refactoring landed right? Is there anything else missing?

[koto]

From jo...@google.com on August 12, 2014 09:09:34

Dummy S2ks should no longer crash the extension, but we don't do anything with them yet.

[koto]

From evn@google.com on August 13, 2014 18:50:35

That's fine.

[koto]

From evn@google.com on August 13, 2014 18:51:09

Status: Fixed