<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jul 12, 2015 at 8:20 PM, Christian Huitema <span dir="ltr"><<a href="mailto:huitema@huitema.net" target="_blank">huitema@huitema.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><p class="MsoNormal"><font size="3" face="Calibri"><span style="font-size:12.0pt">Philip,<u></u><u></u></span></font></p><p class="MsoNormal"><font size="3" face="Calibri"><span style="font-size:12.0pt"><u></u> <u></u></span></font></p><p class="MsoNormal"><font size="3" face="Calibri"><span style="font-size:12.0pt">Your proposed use of names derived from cryptographic keys reminds me a lot of the work with did several years ago with PNRP. The principle was the same, pick a master key and use a hash of that master key as a node’s identity. In our case, it was a key to an entry in a P2P mesh. Leaving aside the specific details of the application, we got lots of feedback from our use of identifiers of form <hash>+<string>, very similar to:<u></u><u></u></span></font></p><p class="MsoNormal"><font size="3" face="Calibri"><span style="font-size:12.0pt"><u></u> <u></u></span></font></p><p class="MsoNormal"><font size="3" face="Calibri"><span style="font-size:12.0pt">    </span></font><span lang="EN"><a href="mailto:mmm%3AMB2GK-6DUF5-YGYYL-JNY5E-RWSHZ%3Aalice@cryptomesh.org" target="_blank">mmm:MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ:alice@cryptomesh.org</a><u></u><u></u></span></p><p class="MsoNormal"><font size="2" face="Calibri"><span lang="EN" style="font-size:11.0pt"><u></u> <u></u></span></font></p><p class="MsoNormal"><font size="2" face="Calibri"><span lang="EN" style="font-size:11.0pt">The main issue is that the hashes are very unwieldy. They cannot be visually verified by the user. An attacker can generate an alternate key whose hash looks “close enough” to the real thing, and then use MITM attack to substitute that when the key is sent from Alice to Bob. Bob performs a visual check, is fooled, and then the communication between Bob and Alice can be intercepted.</span></font></p></div></blockquote><div><br></div><div>I think it is important to separate use of hashes in the human space and below.</div><div><br></div><div>Last week I rewrote my entire crypto layer that I use on top of .NET using fingerprints as the key identification system. Every X.509v3 cert uses the fingerprint as the key identifier for both subject key identifiers and authority, the fingerprint is used as the label on the key store and so on. This has allowed be to remove about 1000 lines of code that were just there to find keys. </div><div><br></div><div><br></div><div>For users, the only operation they are expected to do is compare two fingerprints for equality. And usually they are just checking their own fingerprint which should not change.</div><div><br></div><div>The medium term objective is to get rid of the fingerprint in base32 encoding and use something more easily recognized by a human. For example base65536 encoding with words or images as the symbols. Let us say we could curate a database of such images and store them on a server in a Merkle tree form. We can now generate pictographic representations of the fingerprint. So it should be easy to do the verification on a watch or the like.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><p class="MsoNormal"><font size="2" face="Calibri"><span lang="EN" style="font-size:11.0pt">We explored using a “compressed hash” for verification purposes, which we dubbed “call sign.” The idea was to hash “<a href="mailto:MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ%3Aalice@cryptomesh.org" target="_blank">MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ:alice@cryptomesh.org</a>” plus some “salt”, choosing the salt so the hash ends with a large number of zeros. Let Z be that number. We would then build the call sign from the first N bits of the hash, and publish it as a short Base32 string. The strength of the verification is “N+Z”. For example, N=50 and Z=32 results in a 82 bit strong password, and a 10 character string.</span></font></p></div></blockquote><div><br></div><div>Interesting.</div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><p class="MsoNormal"><font size="2" face="Calibri"><span lang="EN" style="font-size:11.0pt">The point of the small string is that it can be spelled over the phone, or copied from a card, without being too unwieldy.</span></font></p></div></blockquote><div><br></div><div>What I was playing about with was actually similar. To generate my profile, I was running the profile generator lots of times and looking for keys with the strings 'phill', 'hallam', 'phb', etc in the profile. Some folk have done the same with bitcoin handles.</div><div><br></div><div>Now for in person key validation, I am thinking that these days any process is likely to involve QRCodes and smartphones. But that is a separate problem...</div><div><br></div></div><br></div></div>