Re: WireGuard deployment considerations for improved privacy

From: "Fredrik Strömberg" <stromberg@mullvad.net>
To: Henning Reich <henningreich@gmail.com>
Cc: WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: WireGuard deployment considerations for improved privacy
Date: Tue, 15 Jan 2019 15:27:02 +0100	[thread overview]
Message-ID: <CANTUoedLSxrRoDBbiCOYn-xoXT-nAyw-ccfq6kJWThJ9QnmAXA@mail.gmail.com> (raw)
In-Reply-To: <CAOAVeL32OBbhyzrJ-z6nLYMUUJsOFOSVNpbo4wdQN3zV=6yndw@mail.gmail.com>

On Tue, Jan 15, 2019 at 1:05 PM Henning Reich <henningreich@gmail.com> wrote:
>
> Thank for your reply too,
>
> I "use" this list and conversation to get a bit more information about crypto at all (it looks like I need that :-)
>
I see. When I wanted to learn more about network security protocols I
read the RFC for TLS from start to finish a few times. Every time I
didn't understand a word or concept I looked it up on Wikipedia, often
reading the entire article on that concept. In your case maybe read
the WireGuard paper a few times and reference Wikipedia. That's a good
start.

> I try to explain how I understood the problem, and anybdoy can tell me, where I have make a mistake :-)
> From https://www.wireguard.com/protocol/#key-exchange-and-data-packets
> the initiation message and the response use
> initiator.ephemeral_private = DH_GENERATE() and
> responder.ephemeral_private = DH_GENERATE()
>
Correct. Although to be exact DH-Generate returns a keypair (private, public).

> This means (I think), that for every new connection, a new DH-Key is generated. For me (not a programmer) it looks like all other private informations in the messages a encrypted/hashed with values derived from this DH-Key.

Almost. It uses Diffie-Hellman with the ephemeral private key as one component.

In the first message, msg.static is encrypted using a key derived from
DH of the Initiator's ephemeral private key, and the Responder's
static public key (which is already known to Initiator). The first
message also includes the field msg.ephemeral which contains the
Initiator's ephemeral public key, transmitted in the clear.

When the message is received by the Responder, she is able to decrypt
msg.static and learn the Initiator's static public key. You might ask
how that is possible when she doesn't have the Initiator's ephemeral
private key. The reason is that she can derive the correct encryption
key using the Initiator's ephemeral public key, previously transmitted
in the clear, and her (the Responder) static private key.

ECDH ( Initiator's ephemeral private key, Responder's static pubkey )
=
ECDH ( Initiator's ephemeral public key, Responder's static private key )

> Because both site knows the other static key, I would look in the "XX" Row, and there is your quoted destination proberty not exisintg.
>
WireGuard uses Noise_IK, not Noise_XX.

> It's probably possible that I ignore some cryptographic basics or misunderstood same facts. So I hope somebody takes the time and give me some more hints. Thanks
>
No worries. We're all learning something. If you want to learn more
about cryptographic protocols just put in the time. And when you don't
understand something, or suspect that you are wrong, read the whole
thing again. That's what I did :)

Cheers,
Fredrik
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard