Commit Graph
8 Commits
Author SHA1 Message Date
riccardom 1182239faa [client] pqkem: carry a generation on PSK callbacks to drop stale applies
OnNewPSKReady could be applied out of order: two exchanges for a peer can derive
concurrently (one over signal, one over the data path), and the callbacks run
outside the manager lock, so an older exchange's apply could land after a newer
one and restore a stale WireGuard PSK, splitting the tunnel.

Give each exchange a per-peer monotonic generation, assigned under the lock at
creation so a later exchange always carries a higher one, and pass it to
OnNewPSKReady. The host adapter records the newest generation applied per peer
and drops any callback that is not newer, with the check-and-record atomic so the
slow SetPresharedKey call stays off that lock.

Found in cubic review on #7098 (client/internal/pqkem/callbacks.go:12).
2026-10-07 13:30:52 +02:00
riccardom 9041e9a3ee [client] pqkem: document rekey-failure recovery as host-defined
The OnRekeyFailed contract told the host to tear the peer connection down, but
the shipped adapter re-bootstraps over signalling and keeps the previous PSK.
State that recovery is host-defined so another implementation does not perform an
unnecessary teardown.

Found in cubic review on #7098 (client/internal/pqkem/callbacks.go:15).
2026-10-07 13:23:34 +02:00
riccardom cc2d43ee09 [client] pqkem: document the real responder callback timing
OnNewPSKReady's doc claimed the responder fires it "on receiving the confirm",
but there is no confirm round: the responder fires it right after deriving the
PSK from the offer and before sending the answer. Say so, so a host does not
assume the peer has already confirmed the key.

Found in cubic review on #7098 (client/internal/pqkem/callbacks.go:11).
2026-10-07 13:23:22 +02:00
riccardom 3ed4b4fb43 Revert "Introduces a forced WG handshake on initial MLKEM bootstrap."
This reverts commit b5a72eca65.
2026-09-11 14:48:54 +02:00
riccardom a78d587e7a Introduces a forced WG handshake on initial MLKEM bootstrap.
To ensure two peers agree on a key, we need asymmetry. one peer is
the controller ("initiator") the other is the "responder".

Otherwise imagine two offers in parallel driving two answers at the same time

   A                   B
   | <----B-OFFER----- |
   | -----A-OFFER----> |
   |                   |
   |                   |
   ---------------------------------
  |****** ICE + WG Handshake ****** |
   ---------------------------------
   |                   |
   | <----B-ANSWER---- |
   | -----A-ANSWER---> |

PSK is derived on receive of offer, so A and B derive different PSKs.
When WG handshake takes place it picks misaligned PSKs.

So we impair the two nodes and only the offer of one of the two (the controller/initiator)
carries the KEM material.

This means that if the responder OFFER/ANSWER comes first, when the controller/initiator's one
completes (and the genuine PSK is shared between A and B, we need to force a new WG handshake with
the proper keys.
2026-09-11 14:48:54 +02:00
riccardom 3270fc5e18 Bit of renaming
peer -> peerAddrs
have types for remoteID and localID
t.Close log error
Manager SetTransport -> Start
2026-09-11 14:48:54 +02:00
riccardom f8bb816dea Epurate wg refs 2026-09-11 14:48:54 +02:00
riccardom 311c5f8a8c Defines event callbacks 2026-09-11 14:48:54 +02:00