[messaging] Useability of public-key fingerprints

[Nathan Wilcox]

On Wed, Jan 29, 2014 at 4:32 PM, Trevor Perrin <trevp at trevp.net> wrote:

> 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
>
> TACK:     g5p5x.ov4vi.dgsjv.wxctt.c5iul
>
> Bitcoin:  31uEbMgunupShBVTewXjtqbBv5MndwfXhb
>
>
> 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?
>
>
> Trevor
> _______________________________________________
> Messaging mailing list
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging
>


I'm not aware of usability studies.  I expect the different encoding
methods to be more usable in different use cases.  Do we expect users to
read over a phone?  Visually compare?  Cut'n'paste through other text
channels?

I have typed OTR fingerprints, bitcoin keys, and .onions which were
displayed on monitors or friends devices into my mobile's software
keyboard, and I have to say, that's a pain in the ass!  QR codes FTW in
this use case.  Reading long hex clumps over a phone is also a bit of a
pain, and I'd rather have an English word encoding.  We just have to ensure
all users read, speak, and recognize English.


As a tangent, or edge case, I'm a bit fascinated by "affinity" humans have
to encodings, for example vanity hashes.  Silk Road had a vanity .onion
that began with "silk" or something silly like that.  I've also seen vanity
bitcoin addresses.  So how many people use *only* that prefix for
recognition?  This makes phishing attacks more feasible.

I suppose this is a special case of the "look alike" vulnerability where
you might generate near collisions that replace 0/O in the resulting
encoding, except it's interesting to consider the difference in considering
what behaviors make a user vulnerable and to wonder which behaviors are
most prevalent.  If we have natural language word encoding and the intended
use case is reading over a voice channel, now there's an analogous
collision problem with homophones or near-homophones.

With word encodings do people ever selectively regenerate keys until they
"like" the result more, or it's somehow more memorable?  Does memorability
have a measurable entropy correlation?  This might matter more with
passwords or secret sources, rather than verifiers, which instead need to
be recognizably unique and hard to collide against.

If I take a step back when thinking about use cases, I start to wonder
about online verification protocols and the ability to expose fewer
entropic bits which the user has to verify.  I suppose that's completely
orthogonal to the encoding system.


-- 
Nathan Wilcox
Least Authoritarian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140129/551c4d7c/attachment.html>