Wireguard
Created by Antanas Masevičius
This spike investigates possibility to use WG as an alternative VPN service. We want to be sure that WG can be integrated into our core and ported / used in all major platforms: Windows, Linux, Darwin, iOS and Android.
WG offers almost wire speed on modern processors. It also has many features required by modern VPNs. Its lightweight nature (less than 4000 lines in kernel) has many positive sides.
WG can be deployed in Linux kernel space (as a module or compiled in). This means that modified Android kernel versions also can support it in kernel space. For other platforms there is user space implementations that use wireguard-go project. For iOS and android theres separate versions that use wireguard-go through bridges. Those versions are very new and should be considered under development.
All major wireguard related projects are hosted at https://git.zx2c4.com/
Bit outdated todo list exists: https://www.wireguard.com/todo/
Stealthy - no excessive signalling chat
High throughput
Fast connect
Stateless from user perspective - fluent migration between networks (no disconnects)
Decent DOS resistance
Many exploits does not work on it due its simplicity (absence of complex state)
Can be easily blocked: https://lists.zx2c4.com/pipermail/wireguard/2018-September/003289.html
User space implementation is at alpha
WG assumes only static cipher and no cipher negotiation is possible.
It used noise protocol to design its key exchange logic.
Perfect forward security - new key / 2 min
Exchange of public key is encrypted
Prevention of replay attacks - authenticated encryption
1 RTT (round-trip) key exchange
Each site generates pair (send / receive) of symmetric session keys (chacha20)
Key exchange can be initiated any time
Invalid handshakes are ignored
Uses triple-DH
Timers manages state transparently to user - user sees wg0 as stateless
Every transition of state machine is defined (documented)
If theres no conversations for some time - wg becomes silent.
Optional PSK can be used
Ask a server to compute DH() - this is expensive
To rate limit these requests WG uses "cookies" (magic words) which are related (state) with IP address.
When IP address is attributed (determined) token bucket rate limiting is applied.
No dynamic data allocation, just minimal state.
pubkey crypto is slow, wg uses Curve25519 of ECDH, which is one of the fastest.
EC for security: https://tools.ietf.org/html/rfc7748
MAC (message authentication code) ensures message integrity and authenticity (calculated from message and key). WG uses 2 MACs to ensure 1 way RTT
Since WG protocol can be easily identified, we could wrap it around PT (https://www.torproject.org/docs/pluggable-transports.html.en#list-of-pts)
This is discussed here: https://lists.zx2c4.com/pipermail/wireguard/2018-September/003295.html
We need to decide if we want to start integrating this VPN and in what order.
Most mature implementation seems to be Linux kernel space, since it is pure C implementation and was implemented first.
To implement wireguard support for Linux, it would be sufficient to use wg and ip link commands to be able to configure wg tunnel and wg peer. This way we would not be dependent on any 3rd party code, just OS related packages which are already available.
Most of the work would probably be with managing peer data and accounting for sessions statistics. We would need very resilient peer data removal, since stale configuration would mean free access for designated peer.
There is alternative way to manage WG via AF_NETLINK socket, but its not documented and we would need to understand how it works through tools/ipc.c (kernel_set_device()) calls.
Managed to find netlink library for wg, what looks to be on a right track: https://github.com/mdlayher/wireguardctrl it is developed by high profile coder 
discussion here: https://lists.zx2c4.com/pipermail/wireguard/2018-July/003139.html
It should support userspace unix socket soon too.
There also might be two different approaches handling multiple peers (clients) by the node. Creating separate wg device for each peer or relating all peers with 1 central wg device. Former case is more secure. Needs invesgation for pros and cons.
There is a working client in play store, that uses user space for not supported kernels.
https://github.com/WireGuard/wireguard-android
separate todo exists: https://docs.google.com/document/d/15i0Z750eL_OlUyrypUFLF7Hoi5eoF-dTFWj-Rs4RXGI/edit
Android version works really good.
reported as working alpha:
https://lists.zx2c4.com/pipermail/wireguard/2018-May/002854.html
kernel space might be integrated as part of:
https://github.com/LnL7/nix-darwin
Userspace WG, implemented by wireguard-go, would use named pipes to manage wg tunnel device.
Development in progress, also uses golang bridge to call wireguard-go from swift codebase. Implementation is plain and simple. There is still no version in App store, but compiling from source works as expected.
Mysterium team sees Wireguard as a good PT (pluggable transport) option. Also, it looks to be the best option for mobile platforms to be supported along with Myst node. Despite that OpenVPN3 library integration to node is also possible, its size and complexity is out-weighted by Wireguard simplicity and performance.
We chose to implement WG on mobile platforms before working on OpenVPN3