<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jan 29, 2014 at 4:32 PM, Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Some crypto apps let users inspect the public-key hash (aka<br>
"fingerprint") of the other party, so that it can be compared with a<br>
value received through a different channel (phone call, business card,<br>
online directory or website, etc.)<br>
<br>
There's a lot of variation in how public-key fingerprints are<br>
presented (alphabet, number of chars, capitalization, grouping,<br>
separators, etc). For example:<br>
<br>
SSH: 43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8<br>
<br>
GPG: 7213 5CAA EA6B 0980 126A 0371 8373 DD15 4D42 48BD<br>
<br>
OTR: C4E40F71 A92175F8 597A29A7 CB7E0943 B27014FF<br>
<br>
TACK: g5p5x.ov4vi.dgsjv.wxctt.c5iul<br>
<br>
Bitcoin: 31uEbMgunupShBVTewXjtqbBv5MndwfXhb<br>
<br>
<br>
SSH: 128 bits, 32 hex chars<br>
GPG: 160 bits, 40 hex chars<br>
OTR: 160 bits, 40 hex chars<br>
TACK: 125 bits, 25 base32 chars (RFC 4648)<br>
Bitcoin: 200 bits, 34 base58 chars (160 bits hash + version/checksum)<br>
<br>
There's also some fingerprint innovations that aren't widespread:<br>
- Zooko's z-base32<br>
- "Hash extension" from RFC 3972 to squeeze more bits into a smaller<br>
fingerprint<br>
- Phonetic alphabets like the PGPfone wordlist<br>
<br>
Anyways, these are somewhat large strings for users to handle, so it<br>
seems worth trying to streamline the experience and reduce error-rates<br>
due to soundalike or lookalike characters as much as we can.<br>
<br>
I'm a little surprised I can't find more useability research here, except for:<br>
- <a href="https://blog.crypto.cat/2014/01/cryptocat-at-the-openitp-dc-hackathon" target="_blank">https://blog.crypto.cat/2014/01/cryptocat-at-the-openitp-dc-hackathon</a><br>
- <a href="https://moderncrypto.org/mail-archive/curves/2014/000011.html" target="_blank">https://moderncrypto.org/mail-archive/curves/2014/000011.html</a><br>
<br>
Are there other studies? Are there any "best practices" emerging?<br>
<br>
<br>
Trevor<br>
_______________________________________________<br>
Messaging mailing list<br>
<a href="mailto:Messaging@moderncrypto.org">Messaging@moderncrypto.org</a><br>
<a href="https://moderncrypto.org/mailman/listinfo/messaging" target="_blank">https://moderncrypto.org/mailman/listinfo/messaging</a><br>
</blockquote></div><br><br>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?<div>
<br></div><div>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.<br>
<div><br></div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
</div><div><br></div><div>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.</div>
<div><br></div><div><br></div>-- <br>Nathan Wilcox<br>Least Authoritarian<br clear="all"><div><br></div>
</div></div>