package ephemeralpeer

Get desktop application:
View/edit binary Protocol Buffers messages

• rpc RegisterPeerV1 (EphemeralPeerRequestV1, EphemeralPeerResponseV1)

  ephemeralpeer.proto:36

  Derive an ephemeral peer with one or several options enabled, such as PQ or DAITA. The VPN server associates the ephemeral peer with the peer who performed the exchange. Any already existing ephemeral peer for the normal peer is replaced. Each normal peer can have at most one ephemeral peer. The ephemeral peer is mutually exclusive to the normal peer. The server keeps both peers in memory, but only one of them is loaded into WireGuard at any point in time. A handshake from the normal peer unloads the corresponding ephemeral peer from WireGuard and vice versa. A new peer is negotiated to avoid a premature break of the tunnel used for negotiation. A tunnel would break prematurely if configuration such as preshared key were applied before the normal peer received the server's response. This cannot occur now because the client decides when to switch to the ephemeral tunnel. This design also allows the client to switch back to using a non-ephemeral tunnel at any point. The server gives no guarantees how long the ephemeral peer will be valid and working when it's no longer in use. The client should negotiate a new ephemeral peer every time it establishes a new tunnel to the server. The request from the VPN client should contain: * `wg_parent_pubkey` - The public key used by the current tunnel (that the request travels inside). * `wg_ephemeral_peer_pubkey` - A newly generated ephemeral WireGuard public key for the ephemeral peer. The server will associate the new configuration with this key. * One or more requests for different types of options. See the individual messages for more information. If a request is provided, a corresponding response may be returned in the server's response.

  message EphemeralPeerRequestV1

  ephemeralpeer.proto:39

  • bytes wg_parent_pubkey = 1

  • bytes wg_ephemeral_peer_pubkey = 2

  • optional PostQuantumRequestV1 post_quantum = 3

  • optional DaitaRequestV1 daita = 4

  • optional DaitaRequestV2 daita_v2 = 5

  message EphemeralPeerResponseV1

  ephemeralpeer.proto:99

  • optional PostQuantumResponseV1 post_quantum = 1

    The response from the VPN server contains: * `ciphertexts` - A list of the ciphertexts (the encapsulated shared secrets) for all public keys in `kem_pubkeys` in the request, in the same order as in the request. # Deriving the WireGuard PSK The PSK to be used in WireGuard's preshared-key field is computed by XORing the resulting shared secrets of all the KEM algorithms. All currently supported and planned to be supported algorithms output 32 bytes, so this is trivial. Since the PSK provided to WireGuard is directly fed into a HKDF, it is not important that the entropy in the PSK is uniformly distributed. The actual keys used for encrypting the data channel will have uniformly distributed entropy anyway, thanks to the HKDF. KEMs that produce shared secrets of other lengths than 32 bytes, should hash the shared secret with sha256 to generate the 32 bytes used in the XOR step. Mixing with XOR (A = B ^ C) is fine since nothing about A is revealed even if one of B or C is known. Both B *and* C must be known to compute any bit in A. This means all involved KEM algorithms must be broken before the PSK can be computed by an attacker.

  • optional DaitaResponseV2 daita = 2

Used in: DaitaRequestV2

• level_default = 0

• level_1 = 1

• level_2 = 2

• level_3 = 3

• level_4 = 4

• level_5 = 5

• level_6 = 6

• level_7 = 7

• level_8 = 8

• level_9 = 9

• level_10 = 10

Used in: DaitaRequestV2

• undefined = 0

• windows_native = 1

• linux_wg_go = 2

• macos_wg_go = 3

• ios_wg_go = 4

• android_wg_go = 5

• windows_wg_go = 6

Used in: EphemeralPeerRequestV1

• bool activate_daita = 1

Used in: EphemeralPeerRequestV1

• uint32 version = 1

• DaitaPlatform platform = 2

• DaitaLevel level = 3

Used in: EphemeralPeerResponseV1

• repeated string client_machines = 1

• double max_padding_frac = 2

• double max_blocking_frac = 3

Used in: PostQuantumRequestV1

• string algorithm_name = 1

• bytes key_data = 2

The v1 request supports these four algorithms. The algorithms can appear soletary or mixed. Kyber1024 and ML-KEM-1024 cannot be used in the same request as they are just different versions of the same kem. - "Classic-McEliece-460896f", but explicitly identified as "Classic-McEliece-460896f-round3" - "Kyber1024", this is round3 of the Kyber KEM - "ML-KEM-1024". This is the standardized version of ML-KEM (FIPS 203) at the highest strength - "HQC-256". This is the standardized version of HQC at the highest strength

Used in: EphemeralPeerRequestV1

• repeated KemPubkeyV1 kem_pubkeys = 1

Used in: EphemeralPeerResponseV1

• repeated bytes ciphertexts = 1