From cc2d43ee0942b3c10c519818eb28119981b3a234 Mon Sep 17 00:00:00 2001 From: riccardom Date: Wed, 7 Oct 2026 13:23:22 +0200 Subject: [PATCH] [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). --- client/internal/pqkem/callbacks.go | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/client/internal/pqkem/callbacks.go b/client/internal/pqkem/callbacks.go index 3302e2e66..3e22a04d4 100644 --- a/client/internal/pqkem/callbacks.go +++ b/client/internal/pqkem/callbacks.go @@ -6,9 +6,11 @@ package pqkem // the KEM code be extracted as a standalone library. type CallbackHandler interface { // OnNewPSKReady fires when a fresh post-quantum PSK has been derived for a peer - // and must be programmed into the consumer's secure channel. It is invoked at - // the commit point of each side: the initiator on receiving the answer, the - // responder on receiving the confirm. + // and must be programmed into the consumer's secure channel. The protocol has no + // explicit confirm: the initiator fires it on receiving the answer, the responder + // fires it right after deriving the PSK from the offer and before sending that + // answer. A fired callback therefore means the key is derived locally, not that the + // peer has confirmed it — the next offer is the later acknowledgement. OnNewPSKReady(remoteID RemoteID, psk PSK) error // OnRekeyFailed fires when an exchange fails to converge within the allotted