Fix 4 bugs only in the pseudocode.
- bip-0324.mediawiki:326: undefined name responder_K
- memory_cleanse(ecdh_secret, prk, initiator_L, initiator_P, responder_L, responder_K)
+ memory_cleanse(ecdh_secret, prk, initiator_L, initiator_P, responder_L, responder_P)
responder_K is never defined anywhere in the BIP. It should be responder_P.
- bip-0324.mediawiki:356: undefined name ellswift_Y
- send(peer, ellswift_Y + peer.sent_garbage)
+ send(peer, peer.ellswift_ours + peer.sent_garbage)
ellswift_Y is not a variable in scope in respond_v2_handshake. The keypair was generated two lines earlier as peer.privkey_ours, peer.ellswift_ours, so use peer.ellswift_ours instead.
- bip-0324.mediawiki:366: responder drops the already-received prefix bytes
- ellswift_theirs = receive(peer, 64 - len(received_prefix))
+ ellswift_theirs = received_prefix + receive(peer, 64 - len(received_prefix))
respond_v2_handshake consumes the first 1..16 bytes of the peer's key one at a time while testing them against V1_PREFIX. Those bytes are already off the wire, so discarding them leaves ellswift_theirs short by len(received_prefix) with every byte shifted. received_prefix is computed on line 365 and then never used again, which is the tell. Two consequences:
- the wrong-network check ellswift_theirs[4:16] reads the wrong bytes and silently stops working.
- v2_ecdh hashes a different byte string than the initiator hashed for the same key, so the handshake never completes.
Prepending fixes both, and matches the prose at line 361: "The responder performs very similar steps but includes the earlier received prefix bytes in the public key."
- bip-0324.mediawiki:372: initiating hardcoded to True
- initialize_v2_transport(peer, ecdh_secret, initiating=True)
+ initialize_v2_transport(peer, ecdh_secret, initiating=initiating)
Hardcoding True makes the responder encrypt with initiator_P and try to decrypt with responder_P (the initiator's assignment), so neither side can read the other.