Skip to content

CONCEPT Cited by 1 source

Identity-hiding handshake

An identity-hiding handshake is a cryptographic handshake whose wire form does not disclose the long-term identity of either endpoint to a passive observer. The initiator's and responder's static public keys are encrypted under ephemeral keys derived in-handshake, so the wire capture reveals only ephemeral-key exchanges and ciphertext.

Prototypical instance

Noise — the framework underneath WireGuard — is built to be identity-hiding. "Noise goes way out of its way to hide identities during handshakes." (Source: sources/2024-03-12-flyio-jit-wireguard-peers)

In WireGuard specifically, the initiator's static public key is encrypted by the handshake itself. An eavesdropper who captures the UDP traffic cannot tell which of the responder's configured peers is connecting.

Design consequences

Privacy

Identity-hiding handshakes protect the set of peers an endpoint talks to, not just the contents of the conversation. This is the classic motivation: observing "A talks to B" (metadata) is often as sensitive as observing "A tells B secret X" (content).

Infrastructure operators pay a cost for demultiplexing

If the server is running many tunnels and wants to map an incoming connection to a peer-specific config, cert, or routing rule, it can't do so via cleartext. It must perform handshake crypto (or at least the portion of it that decrypts the initiator identity) to demultiplex.

Fly.io's JIT WireGuard peer provisioning is a clean worked example — the gateway wants to know which peer is trying to connect so it can pull that peer's config from the API, but it has to unwrap the first leg of the Noise handshake (~200 lines of code, using the interface private key retrieved from Netlink) to learn that. (Source: sources/2024-03-12-flyio-jit-wireguard-peers)

Middleboxes can't route based on cleartext peer ID

A load balancer or packet filter in front of an identity-hiding endpoint cannot see which peer is connecting and therefore cannot route or policy on that. Options are to give the middlebox the private key (dubious), terminate-and-reoriginate (adds an origin that decrypts everyone's traffic), or use coarser signals (source IP, ephemeral ports, or the full 4-tuple that arrives in-clear).

Contrast

  • Plaintext-ID handshakes (e.g. TLS 1.2 server-auth with ClientHello SNI cleartext; IPsec IKEv2 with cleartext ID payload under MAIN mode) allow cheap middlebox and server demultiplexing but leak metadata.
  • TLS 1.3 with Encrypted Client Hello (ECH) moves SNI inside the handshake and is an explicit move towards identity-hiding at the TLS layer — same direction as Noise, motivated by the same privacy concern.

Seen in

Last updated · 200 distilled / 1,178 read