<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 22, 2015 at 8:40 PM, Bill Cox <span dir="ltr"><<a href="mailto:waywardgeek@gmail.com" target="_blank">waywardgeek@gmail.com</a>></span> wrote:<br><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"><span class="">On Tue, Sep 22, 2015 at 1:35 PM, Phillip Hallam-Baker <span dir="ltr"><<a href="mailto:phill@hallambaker.com" target="_blank">phill@hallambaker.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br></div></blockquote><div><br></div></span><div>This effort sounds like a ton of work requiring a lot of good engineering.  If it did work out, it could be pretty huge.  Is it possible to sign up for an account, yet?  I would be interested in kicking some tires.</div></div></div></div></blockquote><div><br></div><div>Still a ways off, getting close though. About a month of coding and a couple of weeks documenting.</div><div><br></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 class="gmail_quote"><span class=""><div><br></div></span><div>Protecting those private keys is difficult.  Malware might sniff them when the user unlocks them.  A co-worker and I would like to build an open-source a hardware-backed signing library with a common API on the major platforms.  For example, the new SGX Intel extensions can enable more secure rapid key signing.  Some operations have to be super-fast, like Token Binding signature operations, while others, such as unlocking a key when a user enters a password, can be slower, and may rely on signing in secure hardware, such as a TPM.</div></div></div></div></blockquote><div><br></div><div>Protecting the keys is easier if every machine has different keys and keys are never ever removed from devices, only deleted.</div><div><br></div><div>I am particularly interested in Matt Blaze's proxy re-encryption work that was mentioned here. That can be added in as an extra layer of security. </div><div><br></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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>One criticism I'm sure you hear is that the Mesh publishes private keys to the world that can be used to "track" users.  </div></div></div></div></blockquote><div><br></div><div>I am applying some things I learned working for Tim Berners-Lee on the Web. (Meta Mathematical Mesh is MMM which is a reflection of WWW). One of the most important being get the user interface right as your first priority. Don't be afraid to do less than 100% of the problem in the first iteration.</div><div><br></div><div>The web succeeded in part because it just threw out search and referential transparency as problems to be solved by other means. Google and web authoring tools with checking for dead links filled those gaps.</div><div><br></div><div><br></div><div>Once we get something working, we can work on reducing the scope for traffic analysis. Once very simple control is to pad profiles to prevent attacks based on guessing the number of characters used. Another is to use the hash of key values for indexes rather than the values themselves.</div><div><br></div><div>Yet another scheme to consider is that there is a division between the portals (DNS registrar equivalent) and the mesh providers (a sort of confederated registry). At present updates are reflected in real time. But I am thinking that should change and instead a given portal should limit mesh updates to one per profile every 24 hours. That limits the amount of churn in the mesh without significantly exposing users to a portal capture attack (user switching costs must always be negligible). It also limits privacy leakage to a minimum. </div><div><br></div><div><br></div><div>But using the Mesh is going to expose people to a degree of traffic analysis, no question of that. Just like the PGP key servers do. I am ok with that if the amount of leakage isn't significant compared to what we leak by using IP in the first place.</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 dir="ltr"><div class="gmail_extra">Yep, these are tough problems.  To take this to the next level, the Mesh may want to consider more than just signatures.  For example, if suddenly a device is correctly authenticating to the Mess from Russia when all the other user's devices remain in Idaho, that's a signal that maybe more authentication factors are needed.  This can be more devices, answering security questions, or sending an email to the user's default account asking for confirmation.</div></div></blockquote><div><br></div><div>An authentication profile could specify geolocation data and that could be used to limit access. But then you leak more information.</div><div> </div></div></div></div>