[messaging] Useability of public-key fingerprints

[John-Mark Gurney]

Trevor Perrin wrote this message on Wed, Jan 29, 2014 at 16:32 -0800:
> Some crypto apps let users inspect the public-key hash (aka
> "fingerprint") of the other party, so that it can be compared with a
> value received through a different channel (phone call, business card,
> online directory or website, etc.)
> 
> There's a lot of variation in how public-key fingerprints are
> presented (alphabet, number of chars, capitalization, grouping,
> separators, etc).  For example:
> 
> SSH:      43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8
> 
> GPG:      7213 5CAA EA6B 0980 126A  0371 8373 DD15 4D42 48BD
> 
> OTR:      C4E40F71 A92175F8 597A29A7 CB7E0943 B27014FF

above hex...

> TACK:     g5p5x.ov4vi.dgsjv.wxctt.c5iul

not sure what you used for tack...

> Bitcoin:  31uEbMgunupShBVTewXjtqbBv5MndwfXhb

Base58 which drops 0, O, I and l and has no punctuation:
https://en.bitcoin.it/wiki/Base58Check_encoding

> SSH:     128 bits, 32 hex chars
> GPG:     160 bits, 40 hex chars
> OTR:     160 bits, 40 hex chars
> TACK:    125 bits, 25 base32 chars (RFC 4648)
> Bitcoin: 200 bits, 34 base58 chars (160 bits hash + version/checksum)
> 
> There's also some fingerprint innovations that aren't widespread:
>  - Zooko's z-base32
>  - "Hash extension" from RFC 3972 to squeeze more bits into a smaller
> fingerprint
>  - Phonetic alphabets like the PGPfone wordlist
> 
> Anyways, these are somewhat large strings for users to handle, so it
> seems worth trying to streamline the experience and reduce error-rates
> due to soundalike or lookalike characters as much as we can.
> 
> I'm a little surprised I can't find more useability research here, except for:
>  - https://blog.crypto.cat/2014/01/cryptocat-at-the-openitp-dc-hackathon
>  - https://moderncrypto.org/mail-archive/curves/2014/000011.html
> 
> Are there other studies?  Are there any "best practices" emerging?

One thing I'm also surprised is that most of these don't talk about
adding any error correction...  i.e. we could use 1, l and I if we had
a few extra bits that would help identify which ones was which..  Also
I'm surprised that Q isn't included w/ the look alike for O and 0...

Sadly, the bitcoin address does have a 32bit check value, but it's
just a SHA256 result making it close to imposible to correct any
errors...

Though I don't know of any studies that decide what the error profile
of coding schemes like these are which would help decide what any
ECC scheme should be...

Plus, how many times do you actually do a full compare of the finger
print (other than the first/last 16/32 bits)?  All fingerprint displays
should provide a text box to allow you to enter (copy/paste maybe) a
string to validate that they are all the same...

Maybe fingerprints should be limited to 64bits so that its easier/quicker
to compare?  i.e. people don't get comparision fatigue.. I know I do..

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."