Any thought if Windows will embed this natively similar to how Linux pulled WireGuard into the kernel?
Windows can load stuff like this dynamically and doesn't require everything to be compiled into kernel.
WireGuardNT, a high-performance WireGuard implementation for the Windows kernel
151–160 of 187 posts
Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel
#152On one hand I'm super excited for the performance and convenience of in-kernel WireGuard (huray!)
On the other I'm sad that once it's accepted into kernel, it won't be possible to add interesting changes (e.g. obfuscation, forward erasure correction, etc).
I'm torn apart :P
Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel
#153Earlier quoted context omitted.
Wireguard isn't so different from previous protocols establishing encrypted tunnels. Functionally it's IPSEC tunnel mode with all the complexities of IPSEC removed. With a bit of multipoint goodness (ala DMVPN) sprinkled in. The reason why it's hyped is because it's a non-encumbered, gratis, libre, fast replacement for OpenVPN. Yes, it doesn't handle algorithm negotiation. So if there's something wrong with the algor…
No, I think this is essentially wrong. It's hyped because it: (a) Doesn't have selectable or negotiable algorithms and constructions. (b) Exclusively uses modern constructions everybody trusts. (c) Has a minuscule implementation footprint, designed in part to avoid dynamic allocation altogether, that is straightforward to audit. (d) As a result of all of this, it is very fast. (e) As a result of all of this, software…
> Doesn't have selectable or negotiable algorithms and constructions.
NSA likes that.
https://blog.cryptographyengineering.com/2015/10/22/a-riddle...
Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel
#154Can anyone elaborate on how this is implemented? Are they using WFP in some way?
Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel
#155Very impressive performance: > While performance is quite good right now (~7.5Gbps TX on my small test box), not a lot of effort has yet been spent on optimizing it > Jonathan Tooker reported to me that, on his system with an Intel AC9560 WiFi card, he gets ~600Mbps without WireGuard, ~600Mbps with wireguard-go/Wintun over Ethernet, ~95Mbps with wireguard-go/Wintun over WiFi, and ~600Mbps with WireGuardNT over WiFi.…
People always compare bandwidth which is important. Has anyone done any comparisons how latency is affected between various VPN implementations?
Add jitter to the list. Consistency is probably more important for end-user perception than average latency.
Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel
#156Earlier quoted context omitted.
And yet the crowd that pushes WireGuard is the same crowd that pushes the idea that you can't give people a toolkit of crypto stuff, you have to give them a turnkey end-to-end system - indeed the fact that there's e.g. no algorithm selection in WireGuard is touted as a selling point. But how is making the user do their own key exchange/management any different? If you break the key management you break the cryptosyst…
The end-user doesn’t need to do their own key exchange/management. Case in point: https://tailscale.com/ Why should WireGuard bake all that stuff into the core protocol and at the same time make it overly complicated? Donenfeld knows zero about your organization and he doesn’t pretend to do so either. Are you an entusiast home user, a startup of six persons in a garage or are you IBM with over 300000 employees? All o…
> Why should WireGuard bake all that stuff into the core protocol
Because all that stuff is security-critical. All that stuff needs to be incorporated into any audit of the system. Indeed it's probably where the vulnerabilities are going to be.
> Are you an entusiast home user, a startup of six persons in a garage or are you IBM with over 300000 employees? All of those can use WireGuard but will have wildly different needs when it comes to authentication and deployment. There’s no sane one-size-fits-all solution for all kinds of organizations and use-cases.
There needs to be a system that can scale there, especially if the intent is to replace OpenVPN which slotted neatly into standard PKI. If this system pushes more users onto a handful of centralised providers, which seems like what's implicitly being encouraged, then that's not going to end up being good for security.
Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel
#157Earlier quoted context omitted.
Not surprising at all, it is just not worthwhile doing from project management perspective, regardless what a bunch of people on Internet think about it.
Or Microsoft doesn't always make perfectly ideal project management decisions.
Or Microsoft doesn't have a VPN team any more, and hence no project managers to make management decisions for them.
I'm not even kidding that much, the DirectAccess team appears to have been disbanded and all of the open issues were unofficially put in the "will not fix" bucket. I suspect the Always On VPN team is one guy, but probably not working on it full-time.
Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel
#158Will it be possible to fall back to the userspace implementation to use obfuscation software like shadowsocks? Or will it be deprecated? Unfortunately the recent popularity means that almost all DPI software recognize the wireguard handshake.
Jason previously stated in mailing list (couldn't find the thread now) that obfuscation is not a goal of WireGuard.
I'm aware of that. However there are obfuscation software e.g shadowsocks that wraps wireguard or any other connection.
Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel
#159Earlier quoted context omitted.
Jason previously stated in mailing list (couldn't find the thread now) that obfuscation is not a goal of WireGuard.
I'm aware of that. However there are obfuscation software e.g shadowsocks that wraps wireguard or any other connection.
To be honest WireGuard over Shadowsocks is neither common nor recommended, coz essentially it's TCP-over-TCP which will wreak havoc on TCP congestion control.
Unless you mean WireGuard over Shadowsocks UDP transport, but that is even less common.
(Disclaimer: I wrote the official Go port of Shadowsocks https://github.com/shadowsocks/go-shadowsocks2)
Re: WireGuardNT, a high-performance WireGuard implementation for the Windows kernel
#160Earlier quoted context omitted.
Wireguard isn't so different from previous protocols establishing encrypted tunnels. Functionally it's IPSEC tunnel mode with all the complexities of IPSEC removed. With a bit of multipoint goodness (ala DMVPN) sprinkled in. The reason why it's hyped is because it's a non-encumbered, gratis, libre, fast replacement for OpenVPN. Yes, it doesn't handle algorithm negotiation. So if there's something wrong with the algor…
No, I think this is essentially wrong. It's hyped because it: (a) Doesn't have selectable or negotiable algorithms and constructions. (b) Exclusively uses modern constructions everybody trusts. (c) Has a minuscule implementation footprint, designed in part to avoid dynamic allocation altogether, that is straightforward to audit. (d) As a result of all of this, it is very fast. (e) As a result of all of this, software…
I am not challenging that Wireguard is a great technology, but I disagree it is faster than IPsec: it is fast compared to slow IPsec implementation such as the one you have in Linux.
However, AES is hw-accelerated in most systems those days and as a result, using IPsec with AES-256-GCM is usually much faster than Wireguard [1]. Note that if Wireguard was using AES instead of Chach20-Poly1305 I am sure it would be on par, plus I am confident we'll see hw acceleration for Chacha20-Poly1305 in the future too.
So I'd say right now if you need absolute max performance, a good IPsec implementation is much faster than Wireguard.
[1] for example, just running 'openssl speed -evp chacha20-poly1305' vs 'openssl speed -evp aes-256-gcm' on my laptop gives a ~2x speed advantage to AES.