101–110 of 157 posts
Really?
1. RSA & ECC are both too slow for this to be performant
2. Padding???
Certainly you meant "encrypt using a negotiated symmetric key". And earlier you meant to say "negotiate symmetric key with peer"
Earlier quoted context omitted.
As mentioned in the roadmap and the cross-platform page, we're working on a cross-platform userspace client, so Mac and Windows users can use it too. It's in the works!
This comment was marked 'dead', but I think it was a useful question (though maybe a little aggressive in its wording): > So what's the point ? Linux is a niche market. Mac & Windows will be the vast majority of your users and won't enjoy your killer kernel-based feature... Even when Windows/Mac are the vast majority of clients, each client only needs to process its own traffic. The VPN gateway is more likely the bot…
Please let me know if this has already been posted. Is there any worry that someon might perform a DoS attack against a client by replaying a valid packet from the target from different hosts so that the other servers cannot correctly route to the real IP of the target? This is based solely off of the description on the homepage and it might not be possible due to implementation details I'm unaware of.
But an attacker with an active man in the middle position might change the outer (unencrypted) src IP of a packet. However, that src will need to be able to produce authentic replies; otherwise the session will quickly be deemed invalid, so that mitigates any potential very oddball amplification attacks you could dream up. And regardless, an attacker with this kind of active man in the middle can already drop packets at will, so this isn't a vulnerability.
""Encrypt entire IP packet using peer ABCDEFGH's public key."" Really? 1. RSA & ECC are both too slow for this to be performant 2. Padding??? Certainly you meant "encrypt using a negotiated symmetric key". And earlier you meant to say "negotiate symmetric key with peer"
Does the protocol implement any kind of negotiation (ciphers, ...) ? if not, how would you handle future type of attacks against the then hardwired constructions ? I fully agreed that being in-kernel is the right choice for performance, but the chosen constructs excludes the possibility of using any type of existing crypto hardware accelerator that shines in the IPSEC use-case (cache cold data == no cache flush overh…
Fortunately AVX2-accelerated (and soon AVX512-accelerated) ChaPoly is super fast in pretty much all hardware.
Performance comparison would be welcome, especially on low-end hardware. For example, I'm getting 12 Mbps with OpenVPN BF-CBC on AR9341, I wonder what could WireGuard achieve.
Note: This project, despite having the text of the GPL 2 in a file named “COPYING”, is not actually licenced under GPL 2. The actual copyright statement found in source files is “ Copyright 2015-2016 Jason A. Donenfeld . All Rights Reserved. ”. It does not reference the GPL. This means, legally, that nobody can do anything with it. If the author actually meant to licence it under the GPL 2, he should read and follow…
Wow, I launched this 10 minutes ago and somebody already put it on Hacker News. Spectacular! I'm the author of this and would be happy to answer any questions you have.
Couldn't it still be fast and written in a safer than C language considering the security context? (Or we'll still need to get grsec in there... :)
Cheers!
Wow, I launched this 10 minutes ago and somebody already put it on Hacker News. Spectacular! I'm the author of this and would be happy to answer any questions you have.
Nice work, but I'm wondering why does it have to be in kernel? Couldn't it still be fast and written in a safer than C language considering the security context? (Or we'll still need to get grsec in there... :) Cheers!
On a microkernel system, the standard way of connecting to the network stack might be through direct shared memory; and on such a system you could manage to run the VPN in userspace at essentially no cost.
However, on Linux, most of the network stack is in the kernel; the ABI for interacting with network hardware is stable. So while in theory you could write an efficient userspace VPN, it would require you to modify or at very least recompile your applications.
""Encrypt entire IP packet using peer ABCDEFGH's public key."" Really? 1. RSA & ECC are both too slow for this to be performant 2. Padding??? Certainly you meant "encrypt using a negotiated symmetric key". And earlier you meant to say "negotiate symmetric key with peer"
Your concern (1) is valid, but fortunately that's an over-simplification in the casual introduction part of documentation, which I'll fix. Sorry about that. This should read more like, "Encrypt entire IP packet using the symmetric session associated with peer ABCDEFGH." Thanks for pointing this out. As for (2), WireGuard indeed does padding; see the protocol page or the paper for details.
Thanks!