[Cryptography] Robust Linked Timestamps without Proof of Work.

[Phillip Hallam-Baker]

On Sat, Aug 20, 2016 at 3:12 PM, Ray Dillinger <bear at sonic.net> wrote:

>
>
> On 08/20/2016 10:22 AM, Phillip Hallam-Baker wrote:
> > On Sat, Aug 20, 2016 at 12:01 AM, Ray Dillinger <bear at sonic.net> wrote:
>
> >> So you have Trent instead of Sibyl.  Technically either is just as bad,
> >> and nobody wants to take the time and trouble to deal with Trent.  The
> >> whole point of the Proof-of-work thing is that Sibyl can't do damage
> >> for free.  If you're using a Trusted system with gatekeepers who can
> >> screw it over or keep people out, then you don't have Sibyl in the first
> >> place.  But that doesn't mean you have a problem that's any smaller.
>
>
> > ​It isn't Trent though. Its a hundred Trents. And as the BitcOin folk
> > admit, the security of their scheme actually rests on exactly the same
> > principle.
>
> If there isn't a limit on the number of trent, then the system will
> appear to be working fine until people realize that 90% of all the
> trent are actually Sybil.
>
> If one must establish trust relationships with established nodes,
> that just means that it's easier to break in by being ten thousand
> fake nodes gradually allowing the legit nodes to join the network,
> than it is by being one fake node that's trying to quickly join a
> legit network.
>
> I don't think Proof-of-work systems are the only way.  But 'mumble-
> mumble-trust-relationships'  is not sufficient.  Exactly why will
> Sibyl will have more difficulty establishing her ten-thousandth
> fake node (given a "trust relationship" with 9,999 nodes already
> established) than Alice has in establishing her first real one?
>
> Remember: Sibyl doesn't have to break in in a single afternoon.
> She will be there while you're building the walls, when you're
> putting hinges on the doors, and when you're sharing the keys
> around among "yourselves" days, weeks, or months before any hint
> of 'disorderly' or 'noncooperative' behavior begins.
>
> The problem is that you're setting up a system where you want a trust
> relationship but there is a dead hand on 99%+ of the switches that
> decide whom to trust.  The failure of the CA role in the PKI process
> taught us exactly in what ways that doesn't work.
>
> Sibyl will just meet whatever static criteria the dead hands find
> acceptable and get her thousands of fake nodes (all trusted by each
> other) trusted by some of them - then by extension trusted by all the
> others whose dead hands use the trust relationships of that 'some' as
> a criterion.  And she will be there from the beginning, while the
> system is being set up.  Legit nodes will trust her fake nodes because
> they want to join the network.
>
> If the system isn't implemented in a way that allows Sibyl to do this,
> then it will be effectively impossible to set up legitimate nodes
> without individually, personally, contacting thousands of other human
> beings one at a time - rather in the way that CAs were supposed to make
> sure that people were who they said they were, but don't.
>
>
​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.​


​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.

​In comparison, BitCoin exchanges seem to be being breached for millions or
hundreds of millions of dollars on a regular basis. ​

​I don't see how any impartial observer can call the WebPKI a failure and
BitCoin a success.


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.

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.

Trusting MtGox on the other hand...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160820/ae3ab91f/attachment.html>