Why Trust Is Hard

July 16, 2026 · 13 min read

You hand your credit card to a waiter and they disappear into the kitchen. A stranger on the internet asks you to send money to a numbered account. You click “Log in with Google” on a website you’ve never visited before. Each of these is an act of trust, and each relies on a completely different mechanism to work. The fundamental problem of the digital age isn’t speed or storage or bandwidth. It’s trust.

The handshake problem

Trust, at its core, is a prediction about future behaviour. When you trust someone, you’re betting that they’ll do what they said they’d do: deliver the goods, keep your secret, not steal your money. Whether people are trustworthy is the easy half; the hard half is how you verify trustworthiness when you can’t look someone in the eye.

In a small village, trust is easy. You know the baker. You know the blacksmith. You’ve watched them work for years. Reputation spreads by word of mouth, and cheating is expensive because everyone will hear about it. The anthropologist Robin Dunbar estimated that humans can maintain stable social relationships with roughly 150 people (Dunbar’s number) and within that group, trust is managed by memory, gossip, and social pressure. You don’t need contracts with your neighbours. You need memory and a willingness to talk.

But the moment your world expands beyond the village, you have a problem. You’re trading with strangers. You can’t rely on personal reputation because you don’t know these people. You can’t rely on social pressure because your communities don’t overlap. You need a mechanism: something that lets two strangers transact with reasonable confidence that neither will cheat.

Humanity has invented a remarkable number of these mechanisms. Every one of them is a hack, and every one of them is breakable. The history of trust is the history of inventing new mechanisms and then watching clever people defeat them.

Seals, signatures, and the weight of wax

The earliest trust technologies were physical.

Seals date back at least 7,500 years. Mesopotamian cylinder seals (small stone cylinders carved with unique patterns) were rolled across wet clay to leave an impression. The seal proved that a specific person had authorised a document or sealed a container. If you received a jar of grain with an intact seal, you knew it hadn’t been opened since the sender closed it. The seal provided two things at once: authentication (it came from who it claims to come from) and integrity (it hasn’t been tampered with). These two concepts will follow us all the way to modern cryptography.

The technology was simple but effective. Carving a unique seal was hard. Forging one was harder. And if a seal was broken, you knew something had gone wrong, even if you didn’t know what. Seals didn’t prove the content was good, only that the container was unopened. A sealed jar of spoiled grain is still spoiled. Authentication and integrity don’t guarantee quality. They never will.

Signatures are newer than you’d think. Handwritten signatures as a legal instrument only became widespread in the 17th century, largely driven by the English Statute of Frauds (1677), which required certain contracts to be “signed by the party to be charged therewith.” Before that, seals and witnesses served the purpose. The idea that a person’s handwriting is unique and difficult to forge was, and remains, an assumption, not a fact. Forensic document examiners can analyse handwriting with some reliability, but the field has faced serious challenges. A 2009 report by the National Research Council of the US National Academies of Sciences found that many forensic disciplines, including handwriting analysis, lacked rigorous scientific foundations. Signatures work not because they’re unforgeable, but because forging them well enough to fool an expert is expensive.

Notaries add a layer of trusted third party. A notary public witnesses a signature and stamps the document, attesting that the signer appeared in person and presented identification. The notary doesn’t vouch for the content of the document, only that the person who signed it is who they claim to be. This is pure authentication: a trusted intermediary vouching for identity. It’s slow, it requires physical presence, and it costs money. But it’s been working since Roman times. The oldest known notarial acts date to the 2nd century CE.

Letters of introduction solved the long-distance trust problem in a different way. In the 18th and 19th centuries, a gentleman travelling abroad would carry sealed letters from known figures, vouching for his character. Benjamin Franklin carried letters of introduction when he first arrived in Philadelphia in 1723 (though he was only 17, and one imagines the letters were more aspirational than informative). The system worked because forging a letter from a prominent person was risky (they might be contacted to verify), and because carrying a genuine letter meant someone with reputation had staked that reputation on you.

This is a web of trust in its purest form: A trusts B, B vouches for C, so A tentatively trusts C. The chain is only as strong as its weakest link, and it degrades with distance. A trusts B completely, but B’s vouching for C might be casual, and C’s character might have changed since the letter was written. We’ll see this exact pattern again in digital certificate chains and PGP key signing.

The double-spend of trust

There’s a fundamental asymmetry in trust that makes it different from most resources: trust is expensive to build and cheap to destroy.

The sociologist James Coleman formalised this in his 1990 work Foundations of Social Theory. Trust, he argued, is a form of social capital that accumulates through repeated positive interactions and evaporates with a single betrayal. A bank builds trust over decades of reliable service. One fraud scandal destroys it. This asymmetry creates a structural problem: the expected value of betrayal can exceed the expected value of continued cooperation, especially if the betrayer can disappear.

In the physical world, disappearing is hard. You have a face, a home, a community. The baker who sells you rotten bread will see you tomorrow. The cost of cheating is high because your identity is persistent and your reputation follows you.

On the internet, disappearing is trivial. You can create a new email address in thirty seconds. You can operate behind layers of anonymity. You can be anyone, anywhere, and vanish the moment a transaction goes wrong. The internet didn’t just make communication faster; it made identity ephemeral. And ephemeral identity is the enemy of trust.

This is the double-spend problem, borrowed from cryptocurrency but applicable far more broadly. In the physical world, you can’t hand the same banknote to two different people; once it leaves your hand, it’s gone. But a digital file can be copied perfectly and sent to a million people simultaneously. Similarly, a digital identity can be duplicated. A digital promise can be made and broken without consequence. The constraints that made physical trust mechanisms work (the difficulty of forgery, the persistence of identity, the cost of disappearing) evaporate in a digital context.

Why the internet made everything worse

The internet was not designed for trust. This isn’t a bug; it’s a deliberate design decision, and understanding it is essential to understanding why digital trust is so hard.

The original internet protocols. TCP/IP, HTTP, SMTP, were designed in the 1970s and 1980s by academics and military researchers who mostly knew and trusted each other. The ARPANET, the internet’s predecessor, connected a few dozen research institutions. Everyone on the network had been vetted. The protocols didn’t need to handle adversaries because there weren’t any.

SMTP, the email protocol, is a perfect example. When you send an email, the “From” field is simply a text string that the sender fills in. There is no verification. You can send an email claiming to be president@whitehouse.gov and the protocol will deliver it without complaint. This isn’t an oversight; Jon Postel, who wrote the early SMTP specifications, was designing for a network where everyone was a colleague. The idea that someone would lie about their identity simply wasn’t a realistic concern in 1982.

The consequences arrived with scale. As the internet grew from hundreds of nodes to millions and then billions, the assumption of good faith became catastrophically wrong. Spam, phishing, impersonation, fraud: all of these exploit the internet’s naive trust model. The email you received from your bank might actually be from your bank. Or it might be from someone in a different country who typed your bank’s name into the From field. The protocol can’t tell the difference.

DNS, the system that translates domain names (like google.com) to IP addresses, had the same vulnerability. The original DNS protocol trusted all responses implicitly. If a server said “google.com is at 1.2.3.4,” your computer believed it. DNS spoofing (sending false DNS responses to redirect traffic) was first demonstrated in the early 1990s and remains a threat today. DNSSEC, the security extension to DNS, wasn’t standardised until 2005 (RFC 4033-4035) and still isn’t universally deployed.

HTTP, the web protocol, was also designed without authentication. The original web had no concept of identity. When Tim Berners-Lee built the first web server at CERN in 1990, it served pages to anyone who asked, and anyone could claim to be any server. HTTPS (HTTP with encryption) wasn’t standardised until 1994, and widespread adoption didn’t happen until the mid-2010s.

The pattern is consistent: every foundational internet protocol was designed for a small, trusted network, then deployed to an adversarial global one. Every trust mechanism we use today. TLS, OAuth, DNSSEC, SPF/DKIM/DMARC for email, is a retrofit. We’re building security on top of a foundation that was explicitly designed without it.

Three problems masquerading as one

When people say “trust” in a digital context, they usually mean one of three distinct problems. Confusing them is a reliable source of bad security decisions.

Authentication: Are you who you say you are? This is the identity question. Passwords, biometrics, certificates, and passkeys all attempt to answer it. It’s surprisingly hard to do well, as we’ll see in How Identity Works.

Integrity: Has this message been tampered with? If someone sends you a contract, you need to know that the version you’re reading is the version they sent. Hashes, digital signatures, and message authentication codes address this. If you change even one bit of a properly signed message, the signature breaks.

Confidentiality: Can anyone else read this? Encryption, both symmetric and asymmetric, keeps messages private. But encryption without authentication is surprisingly dangerous: if you can’t verify who you’re talking to, it doesn’t matter that nobody else can listen, because the person at the other end might be the attacker. A perfectly encrypted conversation with the wrong person is worse than useless; it gives you false confidence.

These three properties, authentication, integrity, and confidentiality, are sometimes called the CIA triad in information security (no relation to the intelligence agency, though the agency certainly cares about all three). Real trust requires all of them working together, and a failure in any one undermines the others.

There’s a fourth property that often gets overlooked: non-repudiation. This means that the sender can’t later deny having sent a message. In the physical world, a signed contract serves this purpose: your signature is on it, and you can’t plausibly claim otherwise (or at least, it’s very expensive to try). In the digital world, non-repudiation is provided by digital signatures: if you sign a message with your private key, anyone can verify the signature with your public key, and you can’t deny having signed it (unless you claim your private key was stolen, which opens a different can of worms). We’ll get into how this actually works in the encryption and certificate posts.

Trust at scale

The deepest problem with digital trust is scale. Physical trust mechanisms, seals, signatures, notaries, letters of introduction, work because they’re expensive to fake and because the number of parties involved is small. They don’t scale to billions of users making millions of transactions per second.

Consider the problem of buying something from a stranger on the internet. In the physical world, you’d meet in person, inspect the goods, hand over cash, and walk away. Both parties can see each other. Both parties can verify the goods. The transaction is atomic; it happens all at once, in one place. On the internet, you need:

  1. Identity verification: Is the seller real? Are they who they claim to be?
  2. Reputation: Have they done this before? Did it go well?
  3. Escrow: Can the payment be held until the goods arrive?
  4. Dispute resolution: What happens if something goes wrong?
  5. Communication integrity: Has the listing been tampered with? Is the price real?

Every one of these requires a trust mechanism. Physical markets solve them with proximity and social pressure. Digital markets solve them with technology and institutions: payment processors, review systems, dispute resolution services, encrypted connections. The technology is a substitute for the handshake, the eye contact, and the shared community that made trust work in villages.

The economist Avner Greif studied medieval trade networks and found that the Maghribi traders of the 11th century solved a version of this problem without technology. They operated across the Mediterranean (a vast distance for the era) and relied on a tight-knit community network. If a trader cheated a partner, word spread through the network, and the cheater was frozen out of future deals. The sanction was collective and permanent. It worked because the community was small enough for information to travel, and because exit was difficult; there was no alternative network to join.

This is exactly what eBay reinvented in 1995 with its feedback system. The star ratings and review counts are a digital version of the Maghribi traders’ gossip network: cheat someone, and the record follows you. The difference is that eBay’s system operates at a scale the Maghribi traders never imagined (hundreds of millions of users) and the mechanisms for gaming it have scaled accordingly. We’ll explore how reputation systems work (and fail) in the final post in this series.

The trust stack

Here’s the thing that makes digital trust genuinely difficult: it’s not one problem. It’s a stack of problems, each layer depending on the one below.

At the bottom, you need cryptographic primitives: mathematical operations that are easy to perform but hard to reverse. These give you encryption, hashing, and digital signatures. Without them, nothing above works.

On top of that, you need identity systems: ways to bind a cryptographic key to a real-world entity. A public key by itself is just a number. It becomes useful only when you can reliably associate it with a person, a company, or a server.

On top of that, you need trust distribution: ways to extend trust from entities you know to entities you don’t. Certificate authorities, webs of trust, and reputation systems all do this differently, with different trade-offs.

On top of that, you need protocols: agreed-upon sequences of messages that use all the lower layers to accomplish something useful, like establishing a secure connection or authorising a payment.

And on top of everything, you need human behaviour to cooperate. You can build a perfect trust stack and a user will still click “Yes” on a certificate warning they don’t understand, reuse the same password everywhere, and hand over their credentials to a convincing phishing email. The weakest link in every trust system is the human at the keyboard.

The rest of this series will walk up that stack. How Identity Works tackles the identity layer, from passports to passkeys. How Encryption Works covers the cryptographic foundation. How Certificates Work explains the chain of trust that makes HTTPS possible. And How Reputation Systems Work looks at what happens when you can’t use cryptography at all, when trust has to be built from behaviour and observation.

But we start with identity, because everything else depends on it. If you can’t verify who you’re talking to, encryption is pointless, certificates are meaningless, and reputation is fiction. The question “who are you?” turns out to be one of the hardest questions in computer science, and humans have been getting it wrong for centuries even without computers.

These posts are LLM-aided. Backbone, original writing, and structure by Craig. Research and editing by Craig + LLM. Proof-reading by Craig.