(Tailscale cofounder) I see a few comments here that using kernel wireguard would make it faster; it’s not really that simple. In fact, for a while (and we wrote a blog post about it), our optimizations made wireguard-go faster than kernel wireguard because it was better optimized. They adopted some of those improvements and now we’re on to the next order of magnitude together.
For really high bandwidth cases, things like DPDK are the long term best choice and are primarily userspace, for good reasons. Kernel mode is not the pure benefit it once was (if it ever was).
Separately, wireguard itself has a problem that the crypto suite it uses is not supported by hardware accelerators. So if we want to get into the hundreds of gigabits range, we will possibly need to switch packet formats entirely. (But, wireguard also needs to update to support post-quantum so maybe they’ll fix both problems at the same time and we can join in.)
> But, wireguard also needs to update to support post-quantum
It's quantum-resistant if you define a PSK. You still have to distribute the key out of band, but you already have to do that anyways for the public keys of the peers.
Because the public key is the identity in the Wireguard protocol. If Alice and Bob want to communicate with each other over Wireguard, then Alice has to know Bob's public key, and Bob has to know Alice's public key. If they don't already know each other's public keys, then that information has to be exchanged in a secure manner at least once, in order to prevent nosy Mallory from impersonating one of them. 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.
In practice, Alice and Bob will often be two machines that are under control of the same entity, and that entity will transfer the key material from a third machine to the Alice and Bob machines over SSH or HTTPS. In those cases, the out of band mechanism is "SSH/HTTPS via trusted relay machine".
> 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.
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.
apenwarr · · focus · HN ↗
For really high bandwidth cases, things like DPDK are the long term best choice and are primarily userspace, for good reasons. Kernel mode is not the pure benefit it once was (if it ever was).
Separately, wireguard itself has a problem that the crypto suite it uses is not supported by hardware accelerators. So if we want to get into the hundreds of gigabits range, we will possibly need to switch packet formats entirely. (But, wireguard also needs to update to support post-quantum so maybe they’ll fix both problems at the same time and we can join in.)
10000truths · · focus · HN ↗
It's quantum-resistant if you define a PSK. You still have to distribute the key out of band, but you already have to do that anyways for the public keys of the peers.
wisemang · · focus · HN ↗
10000truths · · focus · HN ↗
In practice, Alice and Bob will often be two machines that are under control of the same entity, and that entity will transfer the key material from a third machine to the Alice and Bob machines over SSH or HTTPS. In those cases, the out of band mechanism is "SSH/HTTPS via trusted relay machine".
throw0101c · · focus · HN ↗
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.
10000truths · · focus · HN ↗
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.
throw0101c · · focus · HN ↗
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).
10000truths · · focus · HN ↗