#370 Switch to Fingerprint instead of 32bit key ID

[Robert Pollak]

32bit key ids are not secure, see https://evil32.com/ .

[Daniel Kahn Gillmor]

We've known for years that 32-bit key IDs are not secure. The trouble is, 64-bit key IDs are pretty close to cryptographically insecure (there are already collisions published, and a 2^64 work factor is unlikely to be out of reach of a determined and well-resourced adversary), and humans can't make much sense of full fingerprints.

https://www.debian-administration.org/users/dkg/weblog/105

[Daniel Kahn Gillmor]

Sorry, i forgot the real underlying question:

What should we do about places in the Enigmail UI where key IDs currently exist? Should we just remove them? should we replace them with full fingerprints? should we replace them with human-meaningful but forgeable data (like key creation dates and User IDs), appropriately marked with GnuPG's calculated validity?

I prefer the latter approach, maybe combined with some kind of collapsed view that allows an interested user to get at the fingerprint,

[Patrick Brunschwig]

There are not many places where key 32-bit IDs are actually displayed. I currently only remember the following places:
- Message reading window (when message is signed)
- Key Manager (displays key ID and fingerprint)
- Key selection dialogs
- Key signing dialog (partly)

I don't think that displaying the fingerprint is reasonable. I'd personally vote for displaying the 32-bit key ID together with the UID (i.e. the email address). That's probably better than not displaying the key ID. Wherever sensible, we could also display the fingerprint as additional information (e.g. separate column).

[Daniel Kahn Gillmor]

Thanks for enumerating the locations, Patrick.

Why do you think that displaying the 32-bit key ID together with the UID is better than not displaying the key ID?

• most users don't recognize the key ID, so it's wasted space for them.
• users that do recognize the key ID, or who do work to compare it can be easily fooled by an adversarially-forged key ID, so it's wasted work for them.

We're already trying to display a lot of information to the user (more than they normally get from their MUA). we should avoid clutter, and we should avoid information that looks like it might be cryptographically-strong ("hey, i recognize that unintelligible string!") but actually has no significant cryptographic strength.

As for the locations:

• Message reading window (when message is signed)

The key ID has no place here. Users who want stronger cryptographic details can get that information from the Details dropdown, using "Enigmail Security Info"

• Key Manager (displays key ID and fingerprint)

Given that we have the fingerprint column already, i don't think we need to key ID column here. (the key ID is already present in the end of the fingerprint, so this is wasted space)

• Key selection dialogs

Key selection should show:

* User ID, and the calculated validity 
* key creation date

Humans understand these things and can make sense of them.

It could have an optional column or some expandable way to show the full fingerprint, for those who want stronger cryptographic details.

• Key signing dialog (partly)

The key signing dialog should show only the full fingerprint, and nothing else.

[Patrick Brunschwig]

I tend to agree with you ;-).

[Bernhard M. Wiedemann]

I made a patch for using long key ids:
https://www.zq1.de/~bernhard/linux/enigmail-longkey.patch

It is the result of

find -name \*.js\* | xargs sed -i -e "s/-8, 8/-16, 16/g"

and seems to work pretty well.
I guess, by replacing the 16 with a 40, you could get the full 160-bit fingerprint, but it might make some parts of the UI rather less nice.

[Daniel Kahn Gillmor]

it would be best to simply remove all instances of Key ID except in
places where the user explicitly asks for the fingerprint.

This would result in a nice simplification of the UI overall.

 --dkg

[Patrick Brunschwig]

Fixed by Ludwig on Master. Thanks!