On Wed, Jan 29, 2014 at 4:32 PM, Trevor Perrin <[email protected]> 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 > [email protected] > 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
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
