10 ms·

Just naive, not arrogant (it's ok & encouraged to think through things yourself, even if there already is a solution. you can't expect to come up with actually

Just naive, not arrogant (it's ok & encouraged to think through things yourself, even if there already is a solution. you can't expect to come up with actually new good things on day 1.). You've described the obvious part - this is in any crypto intro course. But it's not even getting the details of that right (which is _a_ challenge) that's interesting, because that's not where wireguard innovates. Well it does actually propose a nice scheme, but still - OpenVPN (in TLS mode), IPSEC (with IKE, else it's DIY) and, in a way, HTTPS already have working schemes. wireguard shines is other areas: the simple (factor 500 smaller code than IPSEC/IKE), performant and fully in-kernel (both unlike OpenVPN) implementation, ifaces instead of xfrm policies (for IPSEC. though that's not entirely far, you can have VTI's. they just don't scale well we've found.), the lessons learned wrt crypto agility (tl;dr: don't), implicit source verification, the beautiful DOS cookie implementation (feels nicer than TA key), that servers are silent/invisible unless you know their public key (cant provoke any response packets without), all connections are p2p. To name a few. Read the Wireguard paper. It's short and very approachable.

tialaramex 8y ago
> lessons learned wrt crypto agility (tl;dr: don't)" This definitely doesn't qualify as a lesson learned. It's maybe, maybe, best current practice, if you squint. We've even seen in other threads the WireGuard author arguing that oh, well, if there's a problem with say key exchange (it has a "conventional" elliptic curve key exchange and so an adversary with a big Quantum Computer definitely breaks that) then you can still rescue with PSKs. And as well as not addressing problems in any other primitive that doesn't stand up to a laugh test. If PSKs were fine you would already use PSKs and not have all this complicated public key dance at all. In reality if there's any problem you have to throw WireGuard itself away. So the hope is maybe all these primitives are fine. And that hope will seem 100% on the money right up until it isn't. We will see then, I think, valuable character information about its designers and key proponents, in light of how they react to that particular lesson, for example in helping people migrate off their now fatally damaged baby. The lesson learned wasn't "don't" it was that "more is always better" is wrong, we didn't need fifteen mediocre symmetric block ciphers without much cryptanalytic research behind them in TLS. But zero agility _definitely_ hasn't proven itself to be the right choice here either, it's just less work to implement.
- jarym 8y ago
  If reconfiguring a service to use a different crypto algo was easy then I’d agree with you. But it is often really hard and makes config difficult. To be honest, when something like WireGuard becomes victim to a flaw in one of the primitives then I’d rather they release a WireGuard 2 to address it - keep as much config the same as possible but throw away any notion of backwards compatibility with vulnerable versions.
- beagle3 8y ago
  Well, it is resistant to to the vast majority of downgrade attacks that plague just about every other widely used crypto protocol. While it's true that if a problem comes up, you'll have to throw the entire protocol suite, that's basically no worse than any of the others. The only case where agility can be helpful is when there are different vulnerabilities known in the MAC, cipher, etc - but there is some combination you can mix-and-match that is still believably secure. I tend to side with Donenfeld here, that this improbable possibility is not worth supporting. Note that WireGuard does have an "entire protocol" version; it's possible to support more than one at a timel; However, it does away with the 50 mix-and-match version that an agile protocol has, and the downgrade attacks that mean the whole thing is only as strong as the weakest combination.
  - tialaramex 8y ago
    > Note that WireGuard does have an "entire protocol" version; Where? Neither a search nor a brief manual inspection of the protocol design mentions such a feature. > it's possible to support more than one at a time Just a moment ago you were cheering on WireGuard's simplicity and lack of vulnerability to downgrade attacks, and now we're talking about how an implementation might actually offer more than one, whereupon you're back to worrying about downgrade attacks. TLS has a number of specific anti-downgrade countermeasures, it will not surprise anyone to discover that WireGuard's paper as well as not describing this "entire protocol" version feature you've mentioned also has nothing about downgrade prevention...
    - tptacek 8y ago
mirimir 8y ago
> ... that servers are silent/invisible unless you know their public key (cant provoke any response packets without) ... Yes, this is beautiful.

tialaramex 8y ago

> lessons learned wrt crypto agility (tl;dr: don't)" This definitely doesn't qualify as a lesson learned. It's maybe, maybe, best current practice, if you squint. We've even seen in other threads the WireGuard author arguing that oh, well, if there's a problem with say key exchange (it has a "conventional" elliptic curve key exchange and so an adversary with a big Quantum Computer definitely breaks that) then you can still rescue with PSKs. And as well as not addressing problems in any other primitive that doesn't stand up to a laugh test. If PSKs were fine you would already use PSKs and not have all this complicated public key dance at all. In reality if there's any problem you have to throw WireGuard itself away. So the hope is maybe all these primitives are fine. And that hope will seem 100% on the money right up until it isn't. We will see then, I think, valuable character information about its designers and key proponents, in light of how they react to that particular lesson, for example in helping people migrate off their now fatally damaged baby. The lesson learned wasn't "don't" it was that "more is always better" is wrong, we didn't need fifteen mediocre symmetric block ciphers without much cryptanalytic research behind them in TLS. But zero agility _definitely_ hasn't proven itself to be the right choice here either, it's just less work to implement.

jarym 8y ago
If reconfiguring a service to use a different crypto algo was easy then I’d agree with you. But it is often really hard and makes config difficult. To be honest, when something like WireGuard becomes victim to a flaw in one of the primitives then I’d rather they release a WireGuard 2 to address it - keep as much config the same as possible but throw away any notion of backwards compatibility with vulnerable versions.
beagle3 8y ago
Well, it is resistant to to the vast majority of downgrade attacks that plague just about every other widely used crypto protocol. While it's true that if a problem comes up, you'll have to throw the entire protocol suite, that's basically no worse than any of the others. The only case where agility can be helpful is when there are different vulnerabilities known in the MAC, cipher, etc - but there is some combination you can mix-and-match that is still believably secure. I tend to side with Donenfeld here, that this improbable possibility is not worth supporting. Note that WireGuard does have an "entire protocol" version; it's possible to support more than one at a timel; However, it does away with the 50 mix-and-match version that an agile protocol has, and the downgrade attacks that mean the whole thing is only as strong as the weakest combination.
- tialaramex 8y ago
  > Note that WireGuard does have an "entire protocol" version; Where? Neither a search nor a brief manual inspection of the protocol design mentions such a feature. > it's possible to support more than one at a time Just a moment ago you were cheering on WireGuard's simplicity and lack of vulnerability to downgrade attacks, and now we're talking about how an implementation might actually offer more than one, whereupon you're back to worrying about downgrade attacks. TLS has a number of specific anti-downgrade countermeasures, it will not surprise anyone to discover that WireGuard's paper as well as not describing this "entire protocol" version feature you've mentioned also has nothing about downgrade prevention...
  - tptacek 8y ago

mirimir 8y ago

> ... that servers are silent/invisible unless you know their public key (cant provoke any response packets without) ... Yes, this is beautiful.