keys2 (42)

The keys2 message is the final step in the quantum-resistant key exchange handshake initiated by an acceptAdd2 message. The original requester, having derived the shared secret, sends back the necessary components for the other party to derive the same secret.

This message ensures both parties arrive at the same symmetric keys for the session without ever exposing the keys themselves on the network.

Core Data Types

Payload Structure

FieldData TypeMinMaxDescription
ecdhPubKeyIxiBytes**The public key part of the sender's newly generated ephemeral ECDH key pair.
mlkemCiphertextIxiBytes**The ML-KEM (Kyber) ciphertext generated by encapsulating a secret using the recipient's ML-KEM public key (from acceptAdd2).
chaChaSaltIxiBytes3232A 32-byte random salt used for deriving the ChaCha symmetric key.
capabilitiesIxiVarUInt**A bitfield of StreamCapabilities supported by the sender.

Behavioral Notes

  • Sender Action: After receiving acceptAdd2, the client (the original requester) performs two cryptographic operations:
    1. Derives an ECDH shared secret using its own ECDH private key and the ecdhPubKey from the acceptAdd2 message.
    2. Generates a new secret and encapsulates it using the mlkemPubKey from the acceptAdd2 message, producing mlkemCiphertext. It then sends its own ecdhPubKey and the mlkemCiphertext in this keys2 message.
  • Recipient Action: The recipient of keys2 (who sent acceptAdd2) performs the final key derivation:
    1. It derives the same ECDH shared secret using its ECDH private key and the ecdhPubKey from this message.
    2. It decapsulates the mlkemCiphertext using its ML-KEM private key to reveal the same encapsulated secret.
    3. It combines both secrets and uses the salts (aesSalt from acceptAdd2 and chaChaSalt from keys2) to derive the final, identical AES and ChaCha session keys.
  • Handshake Completion: Once this message is processed, the handshake is complete (handshakeStatus = 3), and secure, encrypted communication can begin.