Question for app developers, like Enigmail etc. - Identicons
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Sun Jun 4 22:20:50 CEST 2017
I think you're asking about two sort of different things.
on the one hand, you're asserting that the 32-bit keyid isn't sufficient
for any sort of cryptographic verification. that's absolutely correct,
and enigmail really shouldn't be exposing the 32-bit keyID to humans
where it can avoid doing so. I've written more about this here:
You're also asking about graphical representations of the cryptographic
identity -- a graphical representation of a fingerprint, basically.
The community has seen several different proposals of graphical
fingerprint representations in the past, and every one i've seen
gets stuck when faced with the hard questions. In particular:
* is the goal *recognition* of the fingerprint (i.e. "does this
fingerprint look sufficiently similar to the one i've seen in the
past for me to remember it?"), or is the goal *distinguishing* from a
maliciously-crafted fingerprint (i.e. "am i certain that this
fingerprint is an exact match of one that i expect to see from the
peer who i think should have been signing this e-mail?")
* In the "recognition" model, it's not clear that any
cryptographically-strong guarantees are made to the user. So why tie
the visual identity to the cryptographic identity if we think it's
* in the "distinguishing" model, it's not clear that any of the schemes
i've seen are actually better for most humans against a dedicated
attacker who crafts fingerprints to make visual identities that look
similar. do you have any studies showing this capability against a
motivated and technically capable attacker?
I'd generally think that if you're looking for a tool to help people
remember and recognize keys that they've seen before, then a mail user
agent is in a great position to do exactly that: just tell the user
explicitly what they've seen before, how often, etc. why depend on the
human visual cortex or on human ability for numeric recall?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 832 bytes
Desc: not available
More information about the Gnupg-users