[messaging] Useability of public-key fingerprints
infinity0 at pwned.gg
Thu Jan 30 05:06:42 PST 2014
On 30/01/14 12:09, Michael Rogers wrote:
> On 30/01/14 02:24, Ximin Luo wrote:
>> There's a common UI principle that says people can remember 7 (5-9)
>> "things" at once well, where things is some sort of coherent unit.
>> This is consistent with my own personal experience comparing fps.
>> Visually, I definitely find PGP and OTR fps easier to compare than
>> SSH fps, OTR probably marginally more so, since I can hold 8
>> characters in my head at once.
> Eight is above average - we should design for below-average.
My comment was descriptive rather than prescriptive. Also, I don't actually remember 8 characters as separate units, but as a single visual block.
But here it's a tradeoff and not necessarily shorter-is-better. If each block is shorter, you have many more blocks to compare, like the SSH representation, which I find harder to do. I'm talking about my experience, because that's all I have, but someone could do a usability study across many people.
> My intuition about alphabets is that uncertainty about the alphabet
> slows people down. For example, if people don't know that an OTR
> fingerprint is case-insensitive hex, they may read "B03F" as "capital
> b, capital o... no, sorry, zero... three, capital f". Likewise they
> may read out punctuation that's used to group the symbols.
> Think about speaking to a stranger over a bad phone line. Digits can
> be communicated fairly efficiently in groups of two or three. Letters
> require the phonetic alphabet, and if you don't both know that the
> other person's familiar with it, that means "a for alpha, b for bravo"
> rather than "alpha, bravo". If you have to pronounce lowercase and
> uppercase as well, something like base58 becomes less time-efficient
> than decimal digits.
If we agree on a standard, this sort of information would be more in the "public cultural background", like the words in a real dictionary. This benefit can turn out to be even more important than any minor differences between two schemes.
> But I think we can circumvent this whole problem for the common case
> of face-to-face comparison. In that case we can either use QR codes,
> as Daniel suggested, or kick off an ephemeral key exchange with hash
> commitment, use short authentication strings to authenticate the
> ephemeral key exchange, then use the ephemeral authenticated channel
> to compare whatever we need to compare.
If you have tech to do quick comparison of QR codes, then of course we don't need symbolic fps. And we should make an effort to do this whenever feasible, like monkeysign (which unfortunately doesn't work well last time I checked).
And definitely, if both fps are on the actual computer then we should be able to drag-drop (or something) two of them somewhere to compare them, and handle different formats. There is really no reason I have to visually compare between the fps that someone pastes me in a conversation, and what my browser/terminal says (the most common use-case for me, anyway). Actually, this is so simple I might try making this soon.
However, I don't think we'll ever get rid of *all* fps. So we should try to improve these as well. These are two distinct topics, there is no conflict.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 880 bytes
Desc: OpenPGP digital signature
More information about the Messaging