There is a lot of misinformation surrounding WireGuard, so we are continuing to dispel those myths as best we can. In this entry, we are looking at the idea that WireGuard actually supports many different encryption and authentication methods. When in reality, it is a lot more limited than that.
Which encryption does WireGuard support
Whilst the vast majority of other VPN protocols have support for a wide range of cryptosystems, WireGuard is a bit simpler. It only supports one key agreement scheme (Curve25519), and only one AEAD (authenticated encryption with associated data), ChaCha20-Poly1305. In contrast to WireGuard IPSec supports RSA, DSA, ECDSA, Curve25519 and a plethora of other algorithms.
How WireGuard differs from other protocols
Before we start explaining what’s exactly beneath the hood we need to emphasize an important distinction between WireGuard and other well-known protocols. WireGuard is a peer-to-peer protocol. It does not distinguish between server nodes and client nodes nor is there any special functionality assigned to a peer as a consequence of a peer’s role.
Roles, such as a server or a client, are a deployment detail and WireGuard does not care about such details. But, for easier understanding, we’ll address the hide.me peer as a “server” and the customer’s device as a “client”.
WireGuard authentication explained
As with any other asymmetric cryptosystem peers need to authenticate each other before a symmetric session key gets established. The only possible authentication mechanism that WireGuard supports is public key authentication. Other protocols, such as IKEv2 or OpenVPN support username and password authentication, but WireGuard doesn’t. With WireGuard the public keys serve as an authentication material, as a base for key agreement and as a crypto-key routing foundation.
In general, if a peer Alice wishes to prove its identity to some other peer Bob she’ll use her private key to digitally sign some sort of a message. Such a digital signature can be verified by Bob to be authentic, but only if Bob already possesses Alice’s public key. So, Bob needs to get hold of Alice’s public key somehow and in advance.
WireGuard does not provide a facility for such a key exchange, it is stealthy, the public keys need to be set up in advance. If the public key of a peer is not known WireGuard keeps silent. In contrast to WireGuard, TLS, the dominant security protocol, during its handshake provides the server’s public key to the client in the form of a certificate.
How hide.me’s WireGuard authentication works
On hide.me we combined the two. We use HTTPS to establish a short-lived, authenticated and highly secure channel in order to exchange public keys. The customer’s public key will be used then for the WireGuard session which is about to start. Our apps generate fresh private and public key pair on each connection attempt.
Once the server’s and customer’s public keys are in place WireGuard has all the tools it needs to establish a session key over a Curve25519 key agreement scheme. Such a session key is then used by the symmetric ChaCha20-Poly1305 AEAD for the data transfer between the peers.
ChaCha20-Poly1305 explained
ChaCha20-Poly1305 is an AEAD (authenticated encryption with associated data), basically a good combination of a cipher (ChaCha20) and a message authentication code (Poly1305). An AEAD not only encrypts the sensitive data, it authenticates it too (AE part). In addition to the sensitive data other, non-sensitive, data may be included in the final message which gets authenticated as well (AD part). AEADs provide all the three pillars of security:
Confidentiality, integrity and authenticity of the data. Nowadays the dominant AEAD is AES-GCM. It is a construction which consists of the AES-CTR (AES in counter mode) and a GHASH MAC. It is highly secure and has no known vulnerabilities, but it is computationally expensive on platforms other than recent Intel processors.
What’s the verdict
AES is cryptographically stronger than ChaCha20, but it is a lot more taxing. So, it is thought that ChaCha20 is a good “bang-for-your-buck” option when compared to AES, especially on mobile platforms. Before the advent of ChaCha20-Poly1305 there was no alternative to AES-GCM.
Depending on a single AEAD was not an option for large enterprises. What would have happened if a critical vulnerability were to be discovered in AES-GCM? The industry has an alternative now, even if it is not as strong or as fast as AES-GCM it is still a viable option if the AES-GCM fails.