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

Use full fingerprints for search and display #44

Open
ygrek opened this issue Sep 26, 2016 · 0 comments
Open

Use full fingerprints for search and display #44

ygrek opened this issue Sep 26, 2016 · 0 comments

Comments

@ygrek
Copy link
Member

ygrek commented Sep 26, 2016

Original report by kang (Bitbucket: kangsterizer, GitHub: kangsterizer).


Currently SKS shows short key ids when you display keys and long key ids when you search (such as https://gpg.mozilla.org/pks/lookup?op=vindex&search=0xBC17301B491B3F21 <= long key id).

Unfortunately - while most users should manually check full fingerprint and signatures of keys, this does encourage bad behavior such as trusting the short or long key id you're looking for is the correct key.

It would be safer to display the full fingerprint at all times (and certainly to use it for searches).

If proof is needed - recently, https://evil32.com ran a proof of concept and uploaded short key-id collisions to all keys in the strong set. Doing so for long key-id is more time consuming though not impossible, specially for single keys.

I did encounter users that blindly trusted the short keyid and wondered why the keys were revoked (evil32.com revoked all short-key ids they collided with before uploading) - if these were a real attacker, they'd have trusted the key (which again, is the user's mistake - but this is really encouraging this kind of error)

I'm leaving this with the default priority of major as I believe making this a default would greatly help users, though I'm sure there's different opinions.

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

No branches or pull requests

1 participant