WireGuard deployment considerations for improved privacy

[Fredrik Strömberg]

On Mon, Jan 14, 2019 at 1:05 PM Henning Reich <henningreich at gmail.com> wrote:
>
> 3. The attacker uses the VPN server static private key to decrypt the
> recorded handshakes, revealing client static pubkeys.
>
> I think, this is not possible.
> WG use DH for Key-Exchange as other VPNs do (like OpenVPN). Only with recorded traffic, you have no information about the used private DH-Keys --> You still can't decrypt the handshake
> See https://www.wireguard.com/protocol/#key-exchange-and-data-packets
>

First of all, thank you for being the first to reply.

It is true that WireGuard uses ECDH for key exchange, but it does so
in a way that doesn't offer identity hiding forward secrecy.

The page you linked says "WireGuard uses the Noise_IK handshake from
Noise". You can read more about that handshake on this site:
http://www.noiseprotocol.org/noise.html

On the page above under the section "7.7. Payload security properties"
you can read the following for Noise_IK:
"""
Encryption to a known recipient, forward secrecy for sender compromise
only, vulnerable to replay. This payload is encrypted based only on
DHs involving the recipient's static key pair. If the recipient's
static private key is compromised, even at a later date, this payload
can be decrypted. This message can also be replayed, since there's no
ephemeral contribution from the recipient.
"""

If you want to dig into this yourself have a look at the WireGuard
paper. Read section 5.4.2 and read through how msg.static is
calculated.

As an aside, I think it's entirely reasonable at the moment to use
Noise_IK. Identity hiding forward secrecy would require another
round-trip, assuming no experimental crypto. It would increase latency
on setup, decrease DoS protection, and, most importantly in my
opinion, increase the complexity of the protocol state machine. I view
WireGuard as a very secure and trustworthy building block on which to
build. It just so happens that the use case I'm most interested in
introduces some deployment concerns.

Cheers,
Fredrik