<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 20, 2016 at 3:12 PM, Ray Dillinger <span dir="ltr"><<a href="mailto:bear@sonic.net" target="_blank">bear@sonic.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 08/20/2016 10:22 AM, Phillip Hallam-Baker wrote:<br>
> On Sat, Aug 20, 2016 at 12:01 AM, Ray Dillinger <<a href="mailto:bear@sonic.net">bear@sonic.net</a>> wrote:<br>
<br>
</span><span class="">>> So you have Trent instead of Sibyl.  Technically either is just as bad,<br>
>> and nobody wants to take the time and trouble to deal with Trent.  The<br>
>> whole point of the Proof-of-work thing is that Sibyl can't do damage<br>
>> for free.  If you're using a Trusted system with gatekeepers who can<br>
>> screw it over or keep people out, then you don't have Sibyl in the first<br>
>> place.  But that doesn't mean you have a problem that's any smaller.<br>
<br>
<br>
</span><span class="">> ​It isn't Trent though. Its a hundred Trents. And as the BitcOin folk<br>
> admit, the security of their scheme actually rests on exactly the same<br>
> principle.<br>
<br>
</span>If there isn't a limit on the number of trent, then the system will<br>
appear to be working fine until people realize that 90% of all the<br>
trent are actually Sybil.<br>
<br>
If one must establish trust relationships with established nodes,<br>
that just means that it's easier to break in by being ten thousand<br>
fake nodes gradually allowing the legit nodes to join the network,<br>
than it is by being one fake node that's trying to quickly join a<br>
legit network.<br>
<br>
I don't think Proof-of-work systems are the only way.  But 'mumble-<br>
mumble-trust-relationships'  is not sufficient.  Exactly why will<br>
Sibyl will have more difficulty establishing her ten-thousandth<br>
fake node (given a "trust relationship" with 9,999 nodes already<br>
established) than Alice has in establishing her first real one?<br>
<br>
Remember: Sibyl doesn't have to break in in a single afternoon.<br>
She will be there while you're building the walls, when you're<br>
putting hinges on the doors, and when you're sharing the keys<br>
around among "yourselves" days, weeks, or months before any hint<br>
of 'disorderly' or 'noncooperative' behavior begins.<br>
<br>
The problem is that you're setting up a system where you want a trust<br>
relationship but there is a dead hand on 99%+ of the switches that<br>
decide whom to trust.  The failure of the CA role in the PKI process<br>
taught us exactly in what ways that doesn't work.<br>
<br>
Sibyl will just meet whatever static criteria the dead hands find<br>
acceptable and get her thousands of fake nodes (all trusted by each<br>
other) trusted by some of them - then by extension trusted by all the<br>
others whose dead hands use the trust relationships of that 'some' as<br>
a criterion.  And she will be there from the beginning, while the<br>
system is being set up.  Legit nodes will trust her fake nodes because<br>
they want to join the network.<br>
<br>
If the system isn't implemented in a way that allows Sibyl to do this,<br>
then it will be effectively impossible to set up legitimate nodes<br>
without individually, personally, contacting thousands of other human<br>
beings one at a time - rather in the way that CAs were supposed to make<br>
sure that people were who they said they were, but don't.<br><br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small;display:inline">​Like it or not, the fact is that the WebPKI is deployed and meets the intended design goal. The CA model has not failed, it has outperformed its expectations.​</div> </div><div><div class="gmail_default" style="font-size:small;display:inline"><br></div></div><div><div class="gmail_default" style="font-size:small;display:inline">​What has not worked is that the WebPKI worked so well initially that the browser providers decided it was expedient and acceptable to fudge revocation. </div></div></div><br></div><div class="gmail_extra"><div class="gmail_default" style="font-size:small">​In comparison, BitCoin exchanges seem to be being breached for millions or hundreds of millions of dollars on a regular basis. ​</div><br></div><div class="gmail_extra"><div class="gmail_default" style="font-size:small">​I don't see how any impartial observer can call the WebPKI a failure and BitCoin a success.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The only 'mumbling' going on here is invoking Sibyl ​attacks. In the scheme I propose I expect the key servers to establish processes that give each other a reasonable degree of trust and for end users to select a subset they can trust.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Trusting Comodo, Google and Symantec not to all screw up when they are each watching the other and being watched by 97 other Trents isn't a very large leap of faith and there is no Sibyl involved.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Trusting MtGox on the other hand...</div><br></div></div>