mirror of
https://github.com/netbirdio/netbird.git
synced 2026-10-09 15:09:08 +02:00
[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).
This commit is contained in:
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user