Comment by 10000truths
1 day ago
Establishing secrecy is easy if you've already established authenticity - do a key exchange and use the shared secret for your AEAD. Establishing the authenticity is the tricky part, and most encrypted communications protocols offload that to the user in some way:
SSH - the client pubkey has to somehow reach the server's authorized_keys file, and the server fingerprint has to somehow reach the client's known_hosts file.
HTTPS - The root certs have to be present in the client cert store in order for the client to authenticate the servers they connect to.
PGP - People exchange their public keys in key signing parties after verifying each other's identities in person.
> Establishing the authenticity is the tricky part, and most encrypted communications protocols offload that to the user in some way
This statement is mostly true for computers, but a human can look at a (e.g.) Twitter post and know that the account belongs to someone and copy-paste the key in the post, or via an e-mail that has crossed the Internet in a matter that they're confident has not been fiddled with. A computer (process) just has a string of bits that have come in via a socket: it has no other context and so a bunch of infrastructure has to be tapped into (as you listed).
Right, a lot of that trust is implicit and we don't think about it every day. But for threat modeling, it helps to spell out the chain of trust explicitly:
If any of these can be violated, it's an opportunity for attack, be it via a technical exploit, social engineering, political favors, whatever. Ultimately it's up to the user to determine what to trust and what level of risk to accept.