Skip to content
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

Wrong subkey in web encrypt UI #1853

Closed
Manouchehri opened this issue Nov 15, 2015 · 10 comments

Comments

Projects
None yet
3 participants
@Manouchehri
Copy link

commented Nov 15, 2015

The web encryption interface is picking the wrong subkey. It should either use the longest lasting subkey, or at least the most recently created subkey (I would prefer the former). It's wrong on either count and chooses the oldest subkey.

/tmp > mkdir .gnupg-keybase
/tmp > wget -q -O- https://keybase.io/manouchehri/key.asc | gpg --homedir /tmp/.gnupg-keybase/ --import
gpg: WARNING: unsafe permissions on homedir '/tmp/.gnupg-keybase/'
gpg: keybox '/tmp/.gnupg-keybase//pubring.kbx' created
gpg: /tmp/.gnupg-keybase//trustdb.gpg: trustdb created
gpg: key 40839755: public key "David Manouchehri <manouchehri@tuta.io>" imported
gpg: Total number processed: 1
gpg:               imported: 1
/tmp > gpg --homedir /tmp/.gnupg-keybase/ -k
gpg: WARNING: unsafe permissions on homedir '/tmp/.gnupg-keybase/'
/tmp/.gnupg-keybase//pubring.kbx
--------------------------------
pub   rsa4096/40839755 2011-08-20
uid         [ unknown] David Manouchehri <manouchehri@tuta.io>
uid         [ unknown] David Manouchehri <manouchehri@riseup.net>
uid         [ unknown] David Manouchehri <manouchehri@protonmail.ch>
uid         [ unknown] David Manouchehri <manouchehri@i2pmail.org>
uid         [ unknown] David Manouchehri <manouchehri@mail.i2p>
uid         [ unknown] David Manouchehri <david@davidmanouchehri.com>
sub   rsa4096/872082CC 2011-08-20 [expires: 2016-06-01]
sub   rsa4096/70C23A19 2011-08-21 [expires: 2016-06-01]
sub   rsa4096/BE8BCBE0 2012-06-22 [expires: 2016-07-01]
sub   rsa4096/6A5A902C 2012-06-22 [expires: 2016-07-01]
sub   rsa4096/135518DC 2013-06-11 [expires: 2016-08-01]
sub   rsa4096/75874BF2 2013-06-11 [expires: 2016-08-01]

Going from the output above, the default encryption subkey used should be 75874BF2 as it's the longest lasting subkey and also the newest. Yet, the web UI seems to be encrypting with 872082CC instead.

Example of gpg2 using the correct 75874BF2 subkey:

/tmp > gpg --homedir /tmp/.gnupg-keybase/ -r Manouchehri -e manouchehri.key.asc 
gpg: WARNING: unsafe permissions on homedir '/tmp/.gnupg-keybase/'
gpg: 75874BF2: There is no assurance this key belongs to the named user
sub  rsa4096/75874BF2 2013-06-11 David Manouchehri <manouchehri@tuta.io>
 Primary key fingerprint: F0FE 0296 14EA 35BC 9E4F  9768 A6EC FD0C 4083 9755
      Subkey fingerprint: D80F 363D EF26 6322 E05F  A13C 48F9 3D95 7587 4BF2

It is NOT certain that the key belongs to the person named
in the user ID.  If you *really* know what you are doing,
you may answer the next question with yes.

Use this key anyway? (y/N) y

This is quite frustrating as I have to re-layout my keychain and distribute all my subkeys again.

@maxtaco

This comment has been minimized.

Copy link
Contributor

commented Nov 15, 2015

I can take a look. Thanks for the bug report!

@maxtaco

This comment has been minimized.

Copy link
Contributor

commented Nov 15, 2015

Looks like we're just taking the first encryption subkey we find, which explains your findings.

@maxtaco

This comment has been minimized.

Copy link
Contributor

commented Nov 15, 2015

BTW, do you know where in the RFC this behavior is specified?

@maxtaco maxtaco closed this Nov 15, 2015

@maxtaco

This comment has been minimized.

Copy link
Contributor

commented Nov 15, 2015

Should be fixed:

-----BEGIN PGP MESSAGE-----
Version: Keybase OpenPGP v2.0.49
Comment: https://keybase.io/crypto

wcFMA0j5PZV1h0vyAQ/8DNBGmxq9Jd+i7NtXiErU0axPOjJZ5XGI4zKJ8KXCfZKX
fXxCSIiUf0LWgcv0eVeBIyRMg2yOPqH0XYK2nrmbXBJnm8/lT6LIRNVDFFf8ues6
VDFlBFjcKWw8Z37WNL66U2BGyPSyo1tN9cXI0OzyOjrObRIZaA9HV1CI1YFGYFA3
lQ1Gwy1gBwFGdN9BMC1P04OBq3c71xA4yyzBWyoHmUHZdowocUOl72xSRgFErCBU
EJMPUEsk/FGsbw4KzQxuKI4/qyMSZMuboXRbBLS4BID0h7LxxomD4VB1B4lhvFFd
4W5FzJc+stjzMo6AKcD72OR1W0oF+4rv2KhwbU237xspwXRR61vn6M49M5rPONoJ
GrxsnBO/Lh9YeaDHVK34Ol88lNEagViTWkEkDjtFTJU1fRia2sT1QIrqVD9E3haW
qDmWqIjBxODgGvlR79GgnLB94nQ+9hzgnHadLjliEfU6B2p/bbmak90rB4mcdKtF
U2GvTpUmU94RlpWMWHCrilUk6PUSG0O8b5SKg2Hb0qpjH1oA8CKTzjcZZtVVFfP0
i2c3HDiUu4JgIaQMIoxdBEstgGafvvLZB34PaQz7vqy8ymMSjuOocdlOlcKN2tjB
oLX7udCg5trNsJD+yp6Bf1WwS6Dnct77wUY94j8jvEjAEyv+I0wPfzAe2HpnLvbB
wEwDmAo/DQH+BN8BB/0UDn5WWnUyunPqfUUn90Sm7rbFzvnE3RQPvv3SaOFbpZdf
QY6qh2+JjYpPQOuU9NM5cJvvpmYEBYQGDCpoZQ8SC7rDQkeYY8Hza7UqEFWHUXNQ
x6ETW+hjPx6eRVFL0Q+JdFIMMVza7biaLiiwoVjs3KnbBQGz23SQamejEYR4ATED
1gJGE6GjKu0jgkpE9k106hvfUP2GKD8isaUCxZW/Rmrq1XggZv21wt7gqQsl6amK
VNE3BFF34/11NM5ncX5B7rbN6QGnzbdMblxfBKdO/vP2XREoYIYH/7AHx8Mn86KQ
b565/E8eQh+cINudDAUWzrOzQF5o0jsPvHsb6Yq/0koB0noDS/njw/7y4xymlnSf
LoYLGKLqMxPbOCsvU+rSghHzdtJ9ijLAROLpXJkEntHwE6rQendGn/FKRITkafOz
hhPXe4g/r6/pqA==
=MJFP
-----END PGP MESSAGE-----

Which gives:

:pubkey enc packet: version 3, algo 1, keyid 48F93D9575874BF2
    data: [4092 bits]
:pubkey enc packet: version 3, algo 1, keyid 980A3F0D01FE04DF
    data: [2045 bits]

You need a passphrase to unlock the secret key for
user: "keybase.io/max (v0.0.1) <max@keybase.io>"
2048-bit RSA key, ID 01FE04DF, created 2014-02-05 (main key ID 31A6631C)

:encrypted data packet:
    length: 74
    mdc_method: 2
gpg: encrypted with RSA key, ID 75874BF2
gpg: encrypted with 2048-bit RSA key, ID 01FE04DF, created 2014-02-05
      "keybase.io/max (v0.0.1) <max@keybase.io>"
:compressed packet: algo=2
:literal data packet:
    mode u (75), created 1447599400, name="",
@Manouchehri

This comment has been minimized.

Copy link
Author

commented Nov 15, 2015

@maxtaco

This comment has been minimized.

Copy link
Contributor

commented Nov 15, 2015

The one you described. Which link can't you open? The source in kbpgp? The fix is here btw, with an implementation of is_peferable_to.

@Manouchehri

This comment has been minimized.

Copy link
Author

commented Nov 15, 2015

@maxtaco

This comment has been minimized.

Copy link
Contributor

commented Nov 15, 2015

Primary sort by expiration time, descending. Secondary sort by generation time, descending.

@axtl

This comment has been minimized.

Copy link

commented Jun 20, 2016

I think this issue needs to be reopened. This subkey selection strategy is not the same as gpg2 or GPGTools, leading to confusion and UX difficulties.

The strategy used elsewhere is to look at key generation time, and to use the newest encryption subkey that's otherwise still valid (unexpired, unrevoked etc). The main problem with selecting the oldest key is that it may be a non-expiring offline master key, making it rather unusable in the course of regular communication.

@maxtaco

This comment has been minimized.

Copy link
Contributor

commented Jul 22, 2016

We're not selecting the oldest key, just the one further from expiration time. And we always prefer a subkey over the primary key. See here.

Are you getting burned by our strategy, and with which public key?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.