NGCC Round 1

ICCS defines the two categories by what a submission must contain, the security it must meet and how its cost is measured:

• KEM (key encapsulation mechanism): “algorithms for key generation, encapsulation and decapsulation” (submission requirements, Section 2(2)); it “shall satisfy IND-CCA2 security” (evaluation criteria, Section 1); cost is the sizes of public keys, private keys and ciphertexts (Section 2).
• Key exchange: “algorithms for initialization, message generation and shared secret key derivation of two parties” (submission requirements, Section 2(2)); security “under a suitable security model”, for example CK, CK+, eCK or eCK-PFS (evaluation criteria, Section 1); cost is “the number of rounds, and the sizes of the long-term public keys (if any), long-term private keys (if any) and exchanged messages” (Section 2).

ICCS does not restrict how a key-exchange protocol is designed or which security model it uses. A protocol “can be constructed based on a KEM with a small size, or designed directly”, and ICCS “expects static-static key exchange protocols”, where both sides use long-term keys (ICCS feedback, Section 8). The candidate NEV-AKE, for example, builds a two-round authenticated exchange from a KEM and public-key encryption (its specification, Section 3).

Our reading of these definitions: a KEM is a building block, in which one side uses the other’s public key to produce a shared secret and a ciphertext and the other recovers the secret with its private key. A key-exchange protocol is a complete exchange between two parties: who sends what, over how many rounds, and how both derive the key. The models ICCS gives as examples are all authenticated key-exchange models, which also cover whether each side knows who is on the other end.

Classical standards made the same split, as the table shows: NIST’s SP 800-56B and SP 800-56A, and SM2’s Parts 4 and 3. NIST’s post-quantum standards so far stop at the building block: ML-KEM is standardized, and protocols such as TLS build key exchange from it. NGCC also encourages each submitter’s signature, KEM and key exchange to share one hard problem and parameter strategy, forming a suite as SM2 does (submission requirements, Section 2(4)).

Standards also classify key establishment as key transport (one side picks the key) or key agreement (both contribute). That split does not line up with these rows: a KEM can be viewed as either (SP 800-227, Section 2.2). SM2 is published by the Standardization Administration of China as GB/T 32918 (2016); Part 1 is general and Part 5 defines the curve parameters.

Using a KEM for key exchange

To replace conventional Diffie–Hellman, a protocol can use a KEM. One side sends a fresh public key; the other uses it to generate a shared secret and a ciphertext, then sends the ciphertext back. After that one round trip both hold the same secret. If the public key was published beforehand, only the ciphertext needs to be sent.

Post-quantum hybrid key exchange in TLS 1.3, used by HTTPS, combines Diffie–Hellman with a KEM. RFC 9954 describes the framework, modeling each component as a KEM; RFC 10024 defines three combinations of elliptic-curve Diffie–Hellman and ML-KEM.

How key-exchange protocols differ

Protocols differ in these ways; the comparisons below are ours, not ICCS’s.

• Communication. Non-interactive key exchange (NIKE) lets each side derive a shared secret from its own private key and the other’s public key, without a new message once those public keys are known. Diffie–Hellman supports this pattern. KEM-based exchanges require a ciphertext to be sent, but the recipient’s public key can be published in advance. Combined with a symmetric cipher, a KEM gives public-key encryption: the sender encrypts to a recipient who does not need to be online. Examples include ECIES, where the sender combines a fresh Diffie–Hellman key with the recipient’s published one (SP 800-227, Section 5.2.1). A protocol in which both parties must send messages cannot do this.
• Message timing. Some protocols let both sides generate and send their public values independently; fresh Diffie–Hellman shares work this way. Other designs need an earlier message before generating a response. KEM encapsulation needs the recipient’s public key first, so prepublishing that key changes the timing.
• Authentication. Agreeing a secret does not show who holds the other end. A protocol can show it implicitly, by mixing in long-term keys, or explicitly, with signatures. ICCS gives authenticated key-exchange models such as CK and eCK as examples of a suitable security model, without restricting the choice (evaluation criteria, Section 1; feedback, Section 8). NIST’s SP 800-227, Sections 5.2.2–5.2.5 gives KEM-based examples.