java.lang.AssertionError: Unhandled SecretKeyType (should not happen)

[dschuermann]

From G Play:
"I am using a custom-made private key (main key has capability C only, and each subkey has its own capability: S, E and A). I exported the private subkeys only (so that my private key with C capability, used for key-parties only, stays safe). I guess OpenKeychain crashes for this reason: my main private key (the C one) is non-existent on this device (it stays safe at home)!"

java.lang.AssertionError: Unhandled SecretKeyType (should not happen)
at org.sufficientlysecure.keychain.ui.PassphraseDialogActivity$PassphraseDialogFragment.onCreateDialog(PassphraseDialogActivity.java:265)
at android.support.v4.app.DialogFragment.getLayoutInflater(DialogFragment.java:308)
at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:955)
at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1138)
at android.support.v4.app.BackStackRecord.run(BackStackRecord.java:740)
at android.support.v4.app.FragmentManagerImpl.execPendingActions(FragmentManager.java:1501)
at android.support.v4.app.FragmentManagerImpl$1.run(FragmentManager.java:458)
at android.os.Handler.handleCallback(Handler.java:733)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:212)
at android.app.ActivityThread.main(ActivityThread.java:5137)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:515)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:902)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:718)
at dalvik.system.NativeStart.main(Native Method)

[Valodim]

it probably makes sense to just assume a passphrase is needed for this case.... although it would be interesting to know the root cause of this. it could be just non-consolidated databases, but that seems unlikely.

[BlueMax]

OpenKeychain v3.2.1
Android 5.0.2 (CM12)

I get the same. I've imported a private+public key as *.asc file from Enigmail export. The key has no password or timeout defined. When i try to set it as primary key (or change anything else) the app crashes like this:

E/AndroidRuntime(18685): FATAL EXCEPTION: IntentService[KeychainIntentService]
E/AndroidRuntime(18685): Process: org.sufficientlysecure.keychain, PID: 18685
E/AndroidRuntime(18685): java.lang.NullPointerException: Attempt to invoke virtual method 'int org.spongycastle.bcpg.S2K.getType()' on a null object reference
E/AndroidRuntime(18685):    at org.sufficientlysecure.keychain.pgp.PgpKeyOperation.isDummy(PgpKeyOperation.java:1474)
E/AndroidRuntime(18685):    at org.sufficientlysecure.keychain.pgp.PgpKeyOperation.modifySecretKeyRing(PgpKeyOperation.java:403)
E/AndroidRuntime(18685):    at org.sufficientlysecure.keychain.operations.EditKeyOperation.execute(EditKeyOperation.java:86)
E/AndroidRuntime(18685):    at org.sufficientlysecure.keychain.service.KeychainIntentService.onHandleIntent(KeychainIntentService.java:467)
E/AndroidRuntime(18685):    at android.app.IntentService$ServiceHandler.handleMessage(IntentService.java:65)
E/AndroidRuntime(18685):    at android.os.Handler.dispatchMessage(Handler.java:102)
E/AndroidRuntime(18685):    at android.os.Looper.loop(Looper.java:135)
E/AndroidRuntime(18685):    at android.os.HandlerThread.run(HandlerThread.java:61)
W/ActivityManager(717):   Force finishing activity org.sufficientlysecure.keychain/.ui.EditKeyActivity

When it try to validate another imported public key by fingerprint and sign(?) it (during import) with my key this error appears:

I/ActivityManager(717): START u0 {cmp=org.sufficientlysecure.keychain/.ui.PassphraseDialogActivity (has extras)} from uid 10113 on display 0
W/InputMethodManagerService(717): Window already focused, ignoring focus gain of: com.android.internal.view.IInputMethodClient$Stub$Proxy@3f883088 attribute=null, token = android.os.BinderProxy@79c52b1
I/Timeline(18791): Timeline: Activity_idle id: android.os.BinderProxy@379af89b time:12363209
D/AndroidRuntime(18791): Shutting down VM
E/AndroidRuntime(18791): FATAL EXCEPTION: main
E/AndroidRuntime(18791): Process: org.sufficientlysecure.keychain, PID: 18791
E/AndroidRuntime(18791): java.lang.AssertionError: Unhandled SecretKeyType (should not happen)
E/AndroidRuntime(18791):    at org.sufficientlysecure.keychain.ui.PassphraseDialogActivity$PassphraseDialogFragment.onCreateDialog(PassphraseDialogActivity.java:265)
E/AndroidRuntime(18791):    at android.support.v4.app.DialogFragment.getLayoutInflater(DialogFragment.java:308)
E/AndroidRuntime(18791):    at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:955)
E/AndroidRuntime(18791):    at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1138)
E/AndroidRuntime(18791):    at android.support.v4.app.BackStackRecord.run(BackStackRecord.java:740)
E/AndroidRuntime(18791):    at android.support.v4.app.FragmentManagerImpl.execPendingActions(FragmentManager.java:1501)
E/AndroidRuntime(18791):    at android.support.v4.app.FragmentManagerImpl$1.run(FragmentManager.java:458)
E/AndroidRuntime(18791):    at android.os.Handler.handleCallback(Handler.java:739)
E/AndroidRuntime(18791):    at android.os.Handler.dispatchMessage(Handler.java:95)
E/AndroidRuntime(18791):    at android.os.Looper.loop(Looper.java:135)
E/AndroidRuntime(18791):    at android.app.ActivityThread.main(ActivityThread.java:5254)
E/AndroidRuntime(18791):    at java.lang.reflect.Method.invoke(Native Method)
E/AndroidRuntime(18791):    at java.lang.reflect.Method.invoke(Method.java:372)
E/AndroidRuntime(18791):    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:898)
E/AndroidRuntime(18791):    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:693)
E/AndroidRuntime(18791):    at de.robv.android.xposed.XposedBridge.main(XposedBridge.java:117)
W/ActivityManager(717):   Force finishing activity org.sufficientlysecure.keychain/.ui.PassphraseDialogActivity
W/ActivityManager(717):   Force finishing activity org.sufficientlysecure.keychain/.ui.CertifyKeyActivity

I can encrypt/sign/decrypt a mail with K9 though (sending to myself).

The imported key looks like this (private and public):

[Valodim]

handling is improved in a couple of ways in c4d3920. I'm not entirely sure this covers the problem here, we'll see with the bugfix release

[Valodim]

......nope.

[evilstiefel]

Same happens to me when trying to validate a key via fingerprint using my Yubikey.

Upon finishing the process, when I hit the button to confirm the key, the application just crashes with a very similar stack trace.

[Valodim]

Do you have any special type of key, like a stripped master key with divert-to-card subkeys or something?

[evilstiefel]

Exactly like what you described. The master key is not on the Yubikey and not in Openkeychain, just the subkeys.

[Valodim]

in that case, the bug is that certification is not available, and it should throw an error about it rather than try to perform the operation. by design, only the primary key can issue certifications.

[evilstiefel]

You are of course absolutely right. I'm still trying to figure out how to best use the Yubikey without handing over all the keys to the stick itself (lest I lose it). Should not crash, anyway, but I guess then that's not a related issue.

[crosser]

Imagine I want to keep master key on offline storage in a vault, and only carry signing and decryption subkeys with me (on yubikey or on the device). I want to forgo my ability to publicly certify others' keys, to have extra protection for the master key.

But I still want to locally mark others' public keys as verified.

Do you think openkeychain should support such setup?

[dschuermann]

@crosser Create a second key in OpenKeychain. Don't upload it. You can use a name such as "Confirm local key". And then confirm all other keys with this local key.

[crosser]

@dschuermann that works, thanks. But the process could be more user-friendly for this special case.
edit: what I am trying to say, this workflow should be encouraged, and treated as "usual". Instead, you have to make a number of non-default or non-sensical choices:

• specify password for the key, which you may not feel necessary in this case
• specify email address with an '@' and a '.'
• uncheck "encryption" and "signing" checkboxes and only leave "certification"
• when you certify a key, make sure you unckeck the "sync back" (whatever the name)

[dschuermann]

@crosser As you said, it's a special case... we don't advise doing it for average users.

[crosser]

@dschuermann why don't you? It looks like the "best practice" security-wise, no?

[dschuermann]

@crosser It's the tinfoil hat approach ;)
As always in these kind of discussions it is a tradeoff between usability and security. I better don't start rambling about this or it will end like it did here: #975

[crosser]

@dschuermann fair ehough. I just wanted to make a point, it was heard, the rest is up to you folks 👍

[Valodim]

I recently had a conversation with someone who was confused why he wasn't able to certify keys with this sort of key setup. I explained to him that only primary keys could sign, which somewhat surprised him. Now this would be fine, but: This person had written quite the elaborate blog post on how to create a key like this, subkeys on yubikey and master key on a special purpose "air-gapped" machine - without realizing he couldn't use the yubikey to certify keys then. at the point of this writing this post is on the first page of google for relevant keywords for me, so it does its part to shape what is "best practice".

[evilstiefel]

I think I found exactly that post ;). I found a working solution for my "bug/problem" though: I have the subkeys on the Yubikey and the master key in OpenKeychain as well. For certifiying, I still need to input my master password (which is complicated and a pain in the... to type), but that happens rarely.
For signing e-mails and encrypting, I just touch the Yubikey. So, without delving into tinfoil territory, I think I found something that works for me and is still quite practical.

[dschuermann]

I don't see this bug anymore on 3.4.1 in Google Play's developer console. Anyone still having this problem?