[dsr_]

Something like this:

We introduce wireguard2, which is not wire-protocol-compatible with original wireguard. The same configuration files can be used, but you must generate new keys as part of your switch over.

We strongly advise you to stop using original wireguard if there is any possibility of a wealthy, organized, determined attacker intercepting your communications. (See CVE2021-x. and forthcoming paper "64 qubits can deduce Curve25519 points" by D.J. Bernstein et al.)

[upofadown]

So at midnight July 23 2026 everyone upgrades to wireguard2 all at once? Perhaps I am not getting what you are proposing here...

[tptacek]

Just like with TLS and its "ciphersuites", you expose the vulnerable components for as long as (1) you're required to by your users and (2) the risk is bearable. At some point, you stop exposing the vulnerable component at all. Ciphersuite negotiation doesn't free you from this requirement, but it does make it harder to ensure that peers who agree on non-vulnerable parameters are actually able to use them.

None of this is complicated. It's also worth looking back on the history of TLS vulnerabilities to get a sense of just how little ciphersuite negotiation helped anybody.

[upofadown]

My understanding is that Wireguard has no way to do anything other than what it does now. There is no way to use an upgrade in the protocol.

[tptacek]

The same was true of TLS!

[wglb]

And that is a good thing.

[afiori]

not everyone, only a single network at a time. a common use will be corporate VPNs or VPNs on digital ocean-like services, in that case there is little to no reason for interoperability between two distinct network.

or at least you might want different keys anyway