Ask HN: How is WireGuard fast though it uses the public key for encryption?
Wireguard's basic description of how it works [1] says that it encrypts the packets with the public key of the peer (destination) and uses UDP for the transport. In contrast, in the common TLS used for HTTPS, the public key encryption is used only for the initial key exchange wherein a symmetric encryption key is (created/agreed upon and) exchanged for encrypting all data during the lifetime of that connection/session. This is done because encrypting all the data with the public key of the recipient would be slower for close-to-real-time communication needs like the web. My understanding of the common HTTPS/TLS is that the time and energy spent on encrypting data using the public key is quite high when it concerns larger data sizes and larger key sizes.
1. So how is Wireguard faster when it uses the public key of the (destination) peer to encrypt all data all the time? Is it because it uses public keys that are very short, like very short ones in the examples given on its homepage, [1] the likes of which don't seem to be allowed for TLS certificates, vs. 2048 bits commonly used on the web in TLS nowadays?
2. Does it use any schemes not yet adapted into HTTPS/TLS?
3. Would a hypothetical HTTPS/4 (say, built on top of QUIC, which also uses UDP by default) be as fast if it were to use the public keys for encryption rather than exchanging a symmetric encryption key for the session?
Any answers and pointers to read more on (for someone who's nowhere close to being an expert on cryptography) would be helpful.
[1]: https://www.wireguard.com/