What breaks what
Trust or structural assumption

You have the right public key

In plain words

Encryption and signatures only help if you have the genuine public key of the person or site you mean, not an impostor's.

The idea: Every protocol needs a first anchor of trust that math can't provide. Browsers ship a list of certificate authorities. SSH remembers the first key it saw. Signal lets you compare safety numbers in person. DNSSEC builds a chain of signatures up to one root key. Everything after the anchor is checked by cryptography, which makes the anchor the weak link.

Why it matters: Every encrypted channel hands that job to someone: certificate authorities, your first connection, or a fingerprint you compare.

The details

On the map: certificate authorities (TLS), trust on first use (SSH), keys swapped out of band (WireGuard), the key server and safety numbers (Signal), the root key (DNSSEC)

Public-key cryptography protects you only if you are using the right public key. If an attacker gets you to use theirs, the math works perfectly: you encrypt to the attacker, or accept their signatures.

Each protocol hands this problem to someone:

It is a trust assumption, not math, and several of the most famous real-world attacks went through it.

Rests on

If any of these breaks, this breaks too.

Nothing below it on the map: this is a starting point that the rest builds on.

If it falls

If this breaks, these break with it.

References

  1. Fox-IT. Black Tulip: Report of the investigation into the DigiNotar Certificate Authority breach. Report for the Dutch Ministry of the Interior, 2012. zoek.officielebekendmakingen.nl/blg-191225.pdf
  2. B. Laurie, A. Langley and E. Kasper. Certificate Transparency. RFC 6962, 2013. rfc-editor.org/rfc/rfc6962
  3. B. Laurie, E. Messeri and R. Stradling. Certificate Transparency Version 2.0. RFC 9162, 2021. rfc-editor.org/rfc/rfc9162
  4. T. Ylonen. The Secure Shell (SSH) Protocol Architecture. RFC 4251, 2006. rfc-editor.org/rfc/rfc4251
  5. Signal. Safety number updates. Signal blog, 2016. signal.org/blog/safety-number-updates
  6. IANA. DNSSEC Root KSK Ceremonies. 2010. iana.org/dnssec/ceremonies
  7. R. Arends, R. Austein, M. Larson et al. DNS Security Introduction and Requirements. RFC 4033, 2005. rfc-editor.org/rfc/rfc4033