The docs do say: "Finally, WireGuard is cryptographically opinionated. It intentionally lacks cipher and protocol agility. If holes are found in the underlying primitives, all endpoints will be required to update."
ECDH 25519 will fall like a house of cards to a capable quantum computer. Since Wireguard is already entirely DJB, the introduction of a tiny bit of agility with one of Bernstein's submissions (Classic McEliece, NTRU Prime, Post-quantum RSA-Encryption/Signature, and SPHINCS+) seems far from unreasonable.
On the other hand, I'm on Oracle Linux, so I get a new kernel about once a week anyway. Swapping out might not be that traumatic for me, since I can ksplice it into critical systems.
Android, however, cannot do that.
p.s. ...after further reading, Wireguard does have optional, pre-shared symmetric keys. This isn't an ideal solution, but it's something anyway.
"In order to mitigate any future advances in quantum computing, WireGuard also supports a mode in which any pair of peers might additionally pre-share a single 256-bit symmetric encryption key between themselves, in order to add an additional layer of symmetric encryption."
You can use WireGuard with rather expensive but conservative PQ primitives like Classic McEliece using the PSK feature of WireGuard, giving you hybrid PQ secrecy. The PSK feature was explicitly designed for this. The idea is that first you create a normal WireGuard tunnel. Then _through it_, so that it's authenticated, maybe even over boring old TCP, you negotiate your potpourri of experimental post quantum exchanges, maybe several of them if you don't want to trust a first round NIST submission right off the bat. Then you put the resultant key from this into WireGuard's PSK slot, and voila, now you have post quantum forward secrecy.
The Noise protocol framework (on which WireGuard is based) is now looking into doing PQ authentication, so that will be interesting. But until we actually have a clue which PQ primitives to use and have spent some time working out PQ handshakes, I think it's best to keep this all separate and ad-hoc, making it possible with the simple PSK feature.
The PQ algorithms are only adding anything in scenarios where real adversaries can run quantum algorithms to break public key crypto. In those scenarios you don't have worthwhile authentication in WireGuard itself because your adversary broke that with their quantum computer.
The claim of "forward secrecy" seems particularly dubious when resorting to PSKs. Forward secrecy relies upon keys being ephemeral. The PSKs a TLS 1.3 web server remembers for minutes or hours automatically to support fast session resumption maybe count; some semi-detached manual PQ key agreement procedure sounds like it'll get done once and then left in place, no forward secrecy there.
If you believe that demanding agility is "far from unreasonable" I strongly recommend taking that line rather than insisting people should use relatively untried shiny new toys out of fear of a monster that may not actually be under their beds.
I don't know that WireGuard's author will agree, but you at least have a coherent argument that makes sense. Replacing 25519 with NTRU because you're terrified of a bogeyman (in the form of Quantum Computers able to run an algorithm that solves the appropriate hard problem) doesn't make sense.
ECDH 25519 will fall like a house of cards to a capable quantum computer. Since Wireguard is already entirely DJB, the introduction of a tiny bit of agility with one of Bernstein's submissions (Classic McEliece, NTRU Prime, Post-quantum RSA-Encryption/Signature, and SPHINCS+) seems far from unreasonable.
On the other hand, I'm on Oracle Linux, so I get a new kernel about once a week anyway. Swapping out might not be that traumatic for me, since I can ksplice it into critical systems.
Android, however, cannot do that.
p.s. ...after further reading, Wireguard does have optional, pre-shared symmetric keys. This isn't an ideal solution, but it's something anyway.
"In order to mitigate any future advances in quantum computing, WireGuard also supports a mode in which any pair of peers might additionally pre-share a single 256-bit symmetric encryption key between themselves, in order to add an additional layer of symmetric encryption."