Thread by @yassineARK

1/ In a paper written 17 years ago, @NickSzabo4 sheds light on why Trusted Third Parties (TTPs) are massive security holes.

17 years later, the paper is still more relevant than ever: nakamotoinstitute.org/trusted-third-…

Let's dissect what it all means:

2/ As a refresher, here are just a few ex. of trusted third parties as security holes:

MapleChange bit.ly/2OY73vr
Facebook nyti.ms/2NQQNf9
DNS bit.ly/2Svap7n
Yahoo bit.ly/2yIVuOD
Verizon bit.ly/2P1jOFs
Equifax cnnmon.ie/2zegzjn

3/ In the context of cryptography, what is a TTP and how does it work?

A TTP is an entity facilitating interactions between parties who don't trust each other but 'trust' the entity. All communication between the parties is reviewed and managed by the TTP.

4/ Let's say Alice and Bob use a TTP to communicate with each other.

5/ The TTP has a shared secret with both Alice and Bob, call it Ka and Kb. If Alice wants to communicate with Bob, Alice sends a message to the TTP indicating she wants to. The TTP will then generate a new secret key, call it Kab.

6/ The TTP will send Kab encrypted to both Alice and Bob using the shared secrets of both Alice and Bob, Ka and Kb. At this point, both Alice and Bob know Kab and can communicate securely using the encrypted Kab.

7/ What does this imply?

This implies that a TTP is needed for EVERY key exchange and knows ALL session keys.

8/ It means that the systems needs to be 'trusted' to act in your interests. At any moment, the TTP can act against your interest, intentionally or not. A 'trusted' third party implies that there really is no way to verify if the system is operating in your interest.

9/ "So long as there are motives of greed, politics, revenge, those who perform (or supervise) work done by such an entity will provide potential loopholes through which the necessary trust may leak."

10/ Now onto the paper.

11/ A security protocol design that invokes a TTP will by its very nature introduce a security hole into that design. "A problem does not disappear because a designer assumes it away."

12/ By far the highest costs and risks in a system stem from its TTP. Take the Internet DNS as an example:

13/ It's a small part of TCP/IP yet accounts for a majority of the protocol's woes. "Why? Because it is one of the few areas of the TCP/IP stack that depends on a centralized hierarchy of TTPs rather than on protocol negotiations between individual Internet nodes."

14/ The problem is existing TTPs are extremely valuable and are likely here to stay. We economically depend on companies like Visa, Dun and Bradstreet, and Underwriter's Laboratories to connect untrusting strangers into a common trust network.

15/ And, even if minimizing the use of TTPs is more efficient and secure, there are still several reasons why organizations may favor the costlier TTPs:

1. "Limitations of imagination, effort, knowledge, or time"
2. "Entrenched interests."
3. "Mental transaction costs"

16/ If you think about it though, most property throughout history has been personal property.

Imagine depending on a TTP for functionality and security of personal property, like jewelry, operating automobiles, or opening your house door by keys

That would be unacceptable.

17/ So how do we minimize TTPs?

Currently, security designers invoke or assume TTPs to suit the most secure and computationally efficient security protocols.

18/ This dismisses a very important notion: Once a security protocol is implemented the code itself costs very little, and exponential cost functions help reduce costs. The costs of the security protocol itself approach zero, leaving the TTP as the costliest component.

19/ Thus, it makes more sense to estimate first what the TTP will cost instead of designing the security protocol to minimize the cost of the TTP.

20/ In other words, it is better to focus on "the cost of the TTP and design the security protocol to minimize them, rather than assuming TTPs in order to simplify or optimize the efficiency of the security protocol."

21/ Examples given in the paper regarding alternative protocol families include Chaum mixes, multiparty private computations, and Byzantine resilient replicated databases.

22/ This of course, was written before Bitcoin's inception.

"The main point of cryptocurrency was the recognition that trusted third parties are security holes" - @NickSzabo4

23/ Ultimately, "The best "TTP" of all is one that does not exist, but the necessity for which has been eliminated by the protocol design, or which has been automated and distributed amongst the parties to a protocol."

24/ For a deeper dive, check out these links provided by @NickSzabo4

iang.org/ssl/pki_consid…
erights.org/talks/pisa/pap…
onion-router.net/Publications.h…
nakamotoinstitute.org/the-god-protoc…
nakamotoinstitute.org/secure-propert…
openssh.com
iang.org/papers/spock.h…