mirror of
https://github.com/netbirdio/netbird.git
synced 2026-10-13 00:49:07 +02:00
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).
21 lines
1.1 KiB
Go
21 lines
1.1 KiB
Go
package pqkem
|
|
|
|
// CallbackHandler is implemented by the host and invoked by the library. The
|
|
// library only reports events; the host owns the reaction. Keeping this an
|
|
// interface — rather than touching the transport or keying directly — is what lets
|
|
// 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. 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
|
|
// time. The host should tear the peer connection down so it re-establishes, and
|
|
// log a WARN. The library reports the event; it does not dictate the reaction.
|
|
OnRekeyFailed(remoteID RemoteID) error
|
|
}
|