Hacker News Reader

Comment by throw0101c | Hacker News Reader

> How can Alice and Bob exchange their public keys securely? Not with Wireguard, because they'd need to already know each other's public keys for that! So they need to use some other secure mechanism as a bootstrap. Hence, out of band distribution.

I don't think this is quite equivalent: with public keys you 'just' have to establish authenticity, but with PSK you also have to worry about secrecy.

In someone ways it's similar to the PGP/GPG situation: initial secrecy is not the issue, trust is. If you trust someone's Twitter/Bluesky/Mastodon account, they could just the pubkey there; if you think e-mail is 'secure enough' to not be tampered with, they could e-mail you their pubkey. The threshold for 'PSK safety' is probably much higher.

View on HN

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:

  * You trust the browser/OS

  * Browser trusts the root cert store (either embedded in the browser installation or managed by the OS)

  * Root cert authenticates the twitter.com connection

  * Twitter validates the legitimacy of the account (anti-spam/anti-impersonation/verified user etc.)

  * You trust that the person who made the post on the Twitter account is the person you want to communicate with

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.

Reply on news.ycombinator.com