<div dir="ltr"><div class="gmail_default" style="font-size:small">On Tue, Nov 18, 2014 at 3:48 PM, Tony Arcieri <span dir="ltr"><<a href="mailto:bascule@gmail.com" target="_blank">bascule@gmail.com</a>></span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Nov 18, 2014 at 12:29 PM, Maxwell Krohn <span dir="ltr"><<a href="mailto:themax@gmail.com" target="_blank">themax@gmail.com</a>></span> wrote:<br></div><div><span class=""><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">Storage and availability is centralized, but not trust.  Clients don’t trust the server.</blockquote><div><br></div></span><div>This isn't true. A server is authoritative for a user's latest key fingerprint. In the event of a key compromise, a user needs to update their key, but a malicious key server can perform an attack by continuing to serve the compromised key.</div></div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">​As the author of working client code, I’m pretty sure that this is true, actually.  You search Keybase and discover a public key you can download and associated pointers to “proof” assertions.  So you download the public key and that’s the end of your conversation with Keybase.  You go and fetch the posts from Twitter & GitHub & Reddit & so on and check whether those posts are actually signed with that key. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Empirically, the key exists, and it is verifiable, without consulting keybase, that at certain points in time the corresponding private key was in the control  of some entity that also controlled certain Twitter/Reddit/GitHub accounts.  </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I certainly agree that this would be better if it weren’t done through a single web server.  In particular, while the <a href="http://keybase.io">keybase.io</a> implementation is cool and their JSON API is super straightforward to use, they don’t pretend to have a business model or to be anything more than a project run by a couple of guys.  I think the notion of establishing key ownership by leveraging multiple providers of authentication services is super interesting and useful.</div><div class="gmail_default" style="font-size:small"><br></div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div><br></div><div>I would look to a system like The Update Framework as inspiration for how next generation key servers should be designed. Rather than writing off these attacks, they try to systematically address all of them:</div><div><br></div><div><a href="http://freehaven.net/~arma/tuf-ccs2010.pdf" target="_blank">http://freehaven.net/~arma/tuf-ccs2010.pdf</a><span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div><br></div>-- <br><div>Tony Arcieri<br></div>
</font></span></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>- Tim Bray (If you’d like to send me a private message, see <a href="https://keybase.io/timbray" target="_blank">https://keybase.io/timbray</a>)</div></div></div>
</div></div>