10 ms·
Something like this: We introduce wireguard2, which is not wire-protocol-compatible with original wireguard. The same configuration files can be used, but you
by dsr_ 7y ago
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 7y agoSo at midnight July 23 2026 everyone upgrades to wireguard2 all at once? Perhaps I am not getting what you are proposing here...
- tptacek 7y agoJust 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.
- afiori 7y agonot 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