You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: