New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extended private subkey cannot be exported (or imported) #996

Closed
eBrute opened this Issue Nov 4, 2014 · 8 comments

Comments

Projects
None yet
2 participants
@eBrute

eBrute commented Nov 4, 2014

It seems that private subkeys are not imported or exported, when their expire date was extended.

I had some trouble understanding what was going on, but now I can reproduce parts of it:
I created a new key using gpg (3 keypairs (SC,S,E), 4096bit RSA each).
When I import this key into OK and export it again, it works just fine. But when I change the expire date on one of the subkeys and do the same thing, the private part of the subkey is missing.
Here is what I did: https://gist.github.com/eBrute/b814b8a19d88ead010d4

There is no error message thrown by OK at any point.

It seems that always only one subkey is affected.

Note that I either the import or the export could cause the problem. This is where the confusion starts. My real key is not recognized by K9 mail, which would hint towards the import, but then the test key is and can sign and encrypt, which would mean the export ist broken.

@Valodim

This comment has been minimized.

Show comment
Hide comment
@Valodim

Valodim Nov 5, 2014

Member

Hmm, sounds like something goes wrong with canonicalize or merge. Can you paste me the export_testkey_extended.asc file? thanks for your bug report 👍

Member

Valodim commented Nov 5, 2014

Hmm, sounds like something goes wrong with canonicalize or merge. Can you paste me the export_testkey_extended.asc file? thanks for your bug report 👍

@Valodim

This comment has been minimized.

Show comment
Hide comment
@Valodim

Valodim Nov 5, 2014

Member

It's also noteworthy that in your log, the subkey which does /not/ have its expiry changed disappears

Member

Valodim commented Nov 5, 2014

It's also noteworthy that in your log, the subkey which does /not/ have its expiry changed disappears

@eBrute

This comment has been minimized.

Show comment
Hide comment
@eBrute

eBrute Nov 5, 2014

Yeah you are right, didn't notice that.

I have appended 4 files to https://gist.github.com/eBrute/b814b8a19d88ead010d4 (be sure to use the raw version)

  • export_testkey.asc is the full key exported before the expire operation (no pw).
  • export_testkey_extended.asc is the full key exported after the expire operation.
  • reexport_testkey.asc was derived from importing and exporting export_testkey.asc into OK and is fundamentally identical to it
  • reexport_testkey_extended.asc was derived from importing and exporting export_testkey_extended.asc into OK

eBrute commented Nov 5, 2014

Yeah you are right, didn't notice that.

I have appended 4 files to https://gist.github.com/eBrute/b814b8a19d88ead010d4 (be sure to use the raw version)

  • export_testkey.asc is the full key exported before the expire operation (no pw).
  • export_testkey_extended.asc is the full key exported after the expire operation.
  • reexport_testkey.asc was derived from importing and exporting export_testkey.asc into OK and is fundamentally identical to it
  • reexport_testkey_extended.asc was derived from importing and exporting export_testkey_extended.asc into OK
@Valodim

This comment has been minimized.

Show comment
Hide comment
@Valodim

Valodim Nov 5, 2014

Member

Ok so I have some good news and some bad news. The good news is, there is no bug in OpenKeychain, in fact we are doing the right thing™ rejecting this key. The bad news is, it's gpg misbehaving.

Here's a diff between a gpg --list-packets between export_testkey and export_extended_testkey. Note how the certificate of the first subkey rather than the second one is changed, and how its key flags (ie, what operations it may be used for) change from 02 (sign) to 0C (encrypt). This leads me to believe that the cause of this weird behavior is related to this bug, I suspect the newly created subkey binding certificate which should be attached to the second subkey is instead attached to the first one, but obviously doesn't check out which is why OpenKeychain rejects the certificate.

Member

Valodim commented Nov 5, 2014

Ok so I have some good news and some bad news. The good news is, there is no bug in OpenKeychain, in fact we are doing the right thing™ rejecting this key. The bad news is, it's gpg misbehaving.

Here's a diff between a gpg --list-packets between export_testkey and export_extended_testkey. Note how the certificate of the first subkey rather than the second one is changed, and how its key flags (ie, what operations it may be used for) change from 02 (sign) to 0C (encrypt). This leads me to believe that the cause of this weird behavior is related to this bug, I suspect the newly created subkey binding certificate which should be attached to the second subkey is instead attached to the first one, but obviously doesn't check out which is why OpenKeychain rejects the certificate.

@eBrute

This comment has been minimized.

Show comment
Hide comment
@eBrute

eBrute Nov 6, 2014

What a bummer! It would have NEVER occured to me that gpg could have such a bug. It basically means that a key using the debian scheme cannot be extended more than once. Maybe I can figure out how to repair my key, but I fear it will take me ages.

Thanks for the effort though. I really appreciate it.

eBrute commented Nov 6, 2014

What a bummer! It would have NEVER occured to me that gpg could have such a bug. It basically means that a key using the debian scheme cannot be extended more than once. Maybe I can figure out how to repair my key, but I fear it will take me ages.

Thanks for the effort though. I really appreciate it.

@eBrute eBrute closed this Nov 6, 2014

@Valodim

This comment has been minimized.

Show comment
Hide comment
@Valodim

Valodim Nov 6, 2014

Member

I don't have the time to debug this in gpg (mostly because I'm not familiar with its codebase), but it might be a good idea to bug werner about this. It is a fairly serious bug which breaks keys in non-obvious ways that has been around since 2012, after all…

\ edit

ok I looked around their bugtracker, even registered, but couldn't figure out how to write a comment in 5 minutes or less. le shrug.

Member

Valodim commented Nov 6, 2014

I don't have the time to debug this in gpg (mostly because I'm not familiar with its codebase), but it might be a good idea to bug werner about this. It is a fairly serious bug which breaks keys in non-obvious ways that has been around since 2012, after all…

\ edit

ok I looked around their bugtracker, even registered, but couldn't figure out how to write a comment in 5 minutes or less. le shrug.

@eBrute

This comment has been minimized.

Show comment
Hide comment
@eBrute

eBrute Nov 6, 2014

Yeah, horrible website. I will file a new issue and link to the old one.

update: they do this on purpose

To enter a bug into our bug tracker you need to be a registered user. A registered user will be assigned a provisional user role which allows to enter new bugs and to edit these bugs. The user role will be granted by an administrator on demand. Just add remark to your bug report that you wish to work more with the bug tracker. We have these strict rules to avoid spam and keep trolls away from the tracker.

eBrute commented Nov 6, 2014

Yeah, horrible website. I will file a new issue and link to the old one.

update: they do this on purpose

To enter a bug into our bug tracker you need to be a registered user. A registered user will be assigned a provisional user role which allows to enter new bugs and to edit these bugs. The user role will be granted by an administrator on demand. Just add remark to your bug report that you wish to work more with the bug tracker. We have these strict rules to avoid spam and keep trolls away from the tracker.

@eBrute

This comment has been minimized.

Show comment
Hide comment
@eBrute

eBrute Nov 6, 2014

GnuPG 2.1.0 which was released today, does not have this problem 😃
Now I only need to fix my key and then I can finally start using OK.

eBrute commented Nov 6, 2014

GnuPG 2.1.0 which was released today, does not have this problem 😃
Now I only need to fix my key and then I can finally start using OK.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment