Xidian University

Xi'anShaanxiChina kfan@mail.xidian.edu.cn

Xidian University

Xi'anShaanxiChina rdsu@xidian.edu.cn

Xidian University

Xi'anShaanxiChina 23151214152@stu.xidian.edu.cn

Xidian University

Xi'anShaanxiChina jiaqing.ch@stu.xidian.edu.cn

Internet PQ-SecTunnel post-quantum cryptography This document specifies the PQ-SecTunnel protocol, a UDP-based quantum-resistant IP tunnel derived from the WireGuard architecture. Session keys are established by a three-message Noise_IKpsk1kem handshake that replaces Diffie-Hellman with dual Key Encapsulation Mechanism (KEM) operations (static and ephemeral). Authentication is implicit: peers prove possession of long-term KEM private keys through interlocking encapsulations rather than signing the transcript. The protocol is organized as a multi-suite framework. Implementations MAY select ML-KEM-512 or ML-KEM-768 independently for the static and ephemeral KEM roles. This document RECOMMENDS the profile static=ML-KEM-512, ephemeral=ML-KEM-768, AEAD=SM4-GCM, Hash=SM3 (denoted mlkem512-mlkem768-sm4gcm-sm3). Other ML-KEM combinations with the same AEAD/Hash, and additional KEM families such as Aigis-enc (integration ongoing), are optional profiles.

Introduction Traditional IP-layer security protocols such as IPsec commonly rely on classical public-key primitives (RSA, ECDH) for key exchange and authentication. Advances in large-scale quantum computing threaten those constructions. PQ-SecTunnel provides a quantum-resistant tunnel for IP traffic over UDP. The protocol has two phases:

1. Key Agreement Protocol: A 3-message handshake that performs mutual implicit authentication and establishes shared symmetric session keys. This handshake is based on post-quantum Key Encapsulation Mechanisms (KEMs).
2. Data Transport Protocol: The use of the derived session keys with an AEAD cipher to encrypt, authenticate, and transport the encapsulated IP packets over UDP.

PQ-SecTunnel is specified as a suite framework. Algorithm identifiers are fixed at build or deployment time for a given peer pair; there is no in-band suite negotiation in the current design. Peers MUST use identical suite parameters. This revision aligns the handshake description with the project handshake specification (Noise_IKpsk1kem chaining), documents little-endian field encoding as implemented, defines Cookie reply messages and application-layer fragmentation for oversized handshake datagrams, and adopts SM4-GCM / SM3 for the recommended Chinese national cryptography profile.

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Additional terms used in this document:

• AEAD: Authenticated Encryption with Associated Data.
• Initiator: The party that sends Handshake Initiation.
• Responder: The peer that receives Handshake Initiation and sends Handshake Response.
• Static KEM: Long-term KEM used for ct_1 and ct_3.
• Ephemeral KEM: Per-handshake KEM used for E_i key generation and ct_2.
• KDF: HKDF-style extract-and-expand keyed by the chaining key (Section 4.5).
• shk: Shared secret produced by a KEM encapsulation/decapsulation.
• sid_i / sid_r: 32-bit sender indices allocated from the peer index table.
• TK_i / TK_r: Unidirectional transport keys (Initiator-to-Responder / Responder-to-Initiator).
• MAC: Keyed BLAKE2s used for mac1/mac2 DoS cookies (independent of the suite Hash).

Unless otherwise stated, multi-byte integer fields in PQ-SecTunnel messages are encoded in little-endian byte order (WireGuard-compatible). This includes the message type word, sender/receiver indices, data-packet counters, and fragment header integer fields. Cryptographic octet strings (public keys, ciphertexts, MACs, AEAD outputs) are opaque sequences in the order produced by the primitive.

Protocol Overview

Architecture Logical components:

• Certificate / key provisioning: loads long-term KEM public keys (raw configuration or X.509).
• Key agreement: three-message Noise_IKpsk1kem handshake.
• Data plane: AEAD encapsulation of inner IP packets over UDP.
• Virtual network interface: injects/captures plaintext IP for the host stack.
• Optional application-layer fragmentation: splits oversized handshake UDP payloads.

Packet Flow

1. An application emits an inner IP packet.
2. Routing directs the packet to the PQ-SecTunnel virtual interface.
3. The data plane looks up the peer session, assigns a counter, and AEAD-encrypts the inner packet.
4. The outer packet is UDP to the peer endpoint.
5. On receipt, the peer decrypts, anti-replay checks the counter, and injects the inner IP packet.

Threat Model The PQ-SecTunnel protocol is designed to resist the following:

• Confidentiality and integrity of tunnelled IP traffic against classical and quantum eavesdroppers (within the limits of the chosen suite).
• MitM resistance given authentic pre-distributed long-term KEM public keys.
• Forward secrecy for past sessions after ephemeral private key destruction.
• DoS mitigation via mac1/mac2 and Cookie replies before expensive KEM operations.

The protocol does not provide transport reliability. Handshake messages that exceed the path MTU MUST use application-layer fragmentation (Section 6) or otherwise ensure delivery; relying solely on IP fragmentation is NOT RECOMMENDED.

Cryptographic Suites A suite is the 4-tuple (Static_KEM, Ephemeral_KEM, AEAD, Hash). Static_KEM and Ephemeral_KEM MAY differ. For ML-KEM, any combination of ML-KEM-512 and ML-KEM-768 in the two roles is permitted. RECOMMENDED profile for this document: mlkem512-mlkem768-sm4gcm-sm3 (Static=ML-KEM-512, Ephemeral=ML-KEM-768, AEAD=SM4-GCM, Hash=SM3). Other ML-KEM combinations with SM4-GCM/SM3 (for example mlkem512-mlkem512-sm4gcm-sm3 or mlkem768-mlkem768-sm4gcm-sm3) are OPTIONAL (MAY). Aigis-enc parameter sets are envisioned as additional optional KEM choices in the same handshake framework. Normative sizes, OIDs, and interoperability requirements for Aigis-enc are left for a future revision; current implementations MAY experiment but MUST NOT claim conformance to an Aigis profile until specified.

Key Agreement Protocol

Handshake Overview Messages: Handshake Initiation (Initiator), Handshake Response (Responder), Key Confirmation (Initiator). Optional Cookie Reply (Responder) may be sent under load. After Key Confirmation verification, both sides derive TK_i and TK_r. mac1/mac2 are computed over the wire encoding of each handshake message and are verified on receipt before KEM/AEAD processing. They do not enter the C/H chaining state.

Pre-Configuration Before the handshake can be initiated, several prerequisites MUST be met: 1.Long-term Static KEM key pairs: Initiator (S_i^pub, S_i^priv), Responder (S_r^pub, S_r^priv). 2.Each peer MUST possess an authentic copy of the peer's long-term public key before handshake (out-of-band; certificates MAY be used, Section 8).

3. Both peers MUST use the same suite parameters.

Message Formats All handshake and data messages begin with a 32-bit little-endian type field whose low 8 bits carry the message type and whose upper 24 bits MUST be zero (WireGuard-compatible packing). Message types (see also Section 10):

Type	Name
1	Handshake Initiation
2	Handshake Response
3	Key Confirmation
4	Cookie Reply
5	Transport Data

Handshake Initiation This message is sent by the Initiator to begin the handshake. message HandshakeInitiation { u8 type; u8 reserved_zero[3]; u32 sid_i; u8 E_i_pub[Ne]; u8 ct_1[Ns_ct]; u8 static[HashLen+Tag]; u8 time[12+Tag]; u8 mac1[16]; u8 mac2[16]; } Ne / Ns_ct depend on Ephemeral_KEM / Static_KEM. For the recommended profile: Ne = 1184 (ML-KEM-768 public key), Ns_ct = 768 (ML-KEM-512 ciphertext). HashLen = 32 (SM3). Tag = 16 (SM4-GCM).

Handshake Response This message is sent by the Responder after validating the Handshake Initiation message. message HandshakeResponse { u8 type; u8 reserved_zero[3]; u32 sid_r; u32 sid_i; u8 ct_2[Ne_ct]; u8 ct_3[Ns_ct]; u8 empty[Tag]; u8 mac1[16]; u8 mac2[16]; } For the recommended profile: Ne_ct = 1088 (ML-KEM-768 ciphertext).

Key Confirmation This message is sent by the Initiator after validating the Handshake Response message. message KeyConfirmation { u8 type; u8 reserved_zero[3]; u32 sid_i; u32 sid_r; u8 conf[Tag]; u8 mac1[16]; u8 mac2[16]; }

Cookie Reply message CookieReply { u8 type; u8 reserved_zero[3]; u32 receiver_index; u8 nonce[24]; u8 encrypted_cookie[16+16]; } Cookie Reply encrypts a 16-octet cookie under XChaCha20-Poly1305. The AEAD key is derived as BLAKE2s("cookie--" || S_r^pub) with output length as required by XChaCha20-Poly1305 (32 octets). Associated data is the mac1 field of the message that triggered the reply. This construction is independent of the suite AEAD (SM4-GCM) and matches the WireGuard cookie design retained by PQ-SecTunnel.

Handshake State Machine Notation follows the project handshake specification. Hash is the suite hash (SM3). KDF is HKDF-HMAC-Hash (Section 4.5). AEAD.Enc(key, nonce, plaintext, AAD) uses nonce = 12 zero octets for all handshake AEAD operations; AAD is the current transcript hash H before encryption; after encryption, H is updated as H := Hash(H || ciphertext_with_tag). KEM.Enc(pk) denotes standard encapsulation producing (ct, shk). KEM.Dec(sk, ct) produces shk. For static-KEM ciphertexts ct_1 and ct_3, after obtaining shk the implementation MUST replace the value mixed into the chain with Hash(ct) (same length as the KEM shared-secret buffer used by mix_kem_ss). For ephemeral ct_2, the raw shk_2 MUST be mixed (not Hash(ct_2)).

Handshake Initiation (Initiator)

1. sid_i <- allocate sender_index
2. C_0 = Hash(label_1)
3. H_0 = Hash(C_0 || label_2)
4. H_1 = Hash(H_0 || S_r^pub); C_1 = KDF(C_0, S_r^pub)
5. (E_i^priv, E_i^pub) = EphemeralKEM.Gen()
6. H_2 = Hash(H_1 || E_i^pub); C_2 = KDF(C_1, E_i^pub)
7. (ct_1, shk_1) = StaticKEM.Enc(S_r^pub)
8. H_3 = Hash(H_2 || ct_1)
9. ss = Hash(ct_1); (C_3, K_1) = KDF(C_2, ss)
10. static = AEAD.Enc(K_1, 0, Hash(S_i^pub), H_3)
11. H_4 = Hash(H_3 || static)
12. C_4 = KDF(C_3, S_i^pub)

(C_5, Htmp, K_2) = KDF(C_4, H_4 || PSK); H_5 = Hash(H_4 || Htmp)

13. time = AEAD.Enc(K_2, 0, t_now, H_5)
14. H_6 = Hash(H_5 || time)
15. mac1 / mac2 as in Section 4.6
16. Send HandshakeInitiation

label_1 is the protocol name string for the suite (RECOMMENDED example: "Noise_IKpsk1kem_SM4GCM_SM3_EphemMLKEM768"). label_2 is the identifier string (example: "PQWireGuard v2 zx2c4 Jason@zx2c4.com"). Both include the terminating NUL octet when hashed, matching the reference implementation.

Handshake Response (Responder)

1. Verify mac1/mac2; on failure silently drop
2. Recompute C_0..H_6 through decryption of static and time as Initiation inverse
3. sid_r <- allocate sender_index
4. (ct_2, shk_2) = EphemeralKEM.Enc(E_i^pub)
5. H_7 = Hash(H_6 || ct_2); C_6 = KDF(C_5, ct_2)
6. C_7 = KDF(C_6, shk_2)
7. (ct_3, shk_3) = StaticKEM.Enc(S_i^pub)
8. H_8 = Hash(H_7 || ct_3)
9. ss = Hash(ct_3); C_8 = KDF(C_7, ss)
10. (C_9, Htmp, K_3) = KDF(C_8, H_8 || PSK); H_9 = Hash(H_8 || Htmp)
11. empty = AEAD.Enc(K_3, 0, empty, H_9)
12. H_10 = Hash(H_9 || empty)
13. (C_10, K_4) = KDF(C_9, empty)
14. mac1/mac2; send HandshakeResponse

Key Confirmation (Initiator)

1. Verify mac1/mac2; on failure abort
2. shk_2 = EphemeralKEM.Dec(E_i^priv, ct_2); destroy E_i^priv
3. H_7 = Hash(H_6 || ct_2); C_6 = KDF(C_5, ct_2)
4. C_7 = KDF(C_6, shk_2)
5. shk_3 = StaticKEM.Dec(S_i^priv, ct_3)
6. H_8 = Hash(H_7 || ct_3)
7. ss = Hash(ct_3); C_8 = KDF(C_7, ss)
8. (C_9, Htmp, K_3) = KDF(C_8, H_8 || PSK); H_9 = Hash(H_8 || Htmp)
9. AEAD.Dec(K_3, 0, empty, H_9); require empty plaintext
10. H_10 = Hash(H_9 || empty)
11. (C_10, K_4) = KDF(C_9, empty)
12. conf = AEAD.Enc(K_4, 0, empty, H_10)
13. mac1/mac2; send KeyConfirmation
14. (TK_i, TK_r) = KDF(C_10, empty_input)

Key Confirmation (Responder)

1. Verify mac1/mac2; on failure abort
2. AEAD.Dec(K_4, 0, conf, H_10); require empty plaintext
3. (TK_i, TK_r) = KDF(C_10, empty_input)

Key Derivation and Chaining KDF is Hugo Krawczyk's HKDF using HMAC with the suite Hash (HMAC-SM3 for the recommended profile) . Let CK be the chaining key. KDF(CK, input) producing n outputs means: PRK = HMAC(CK, input); then Expand with counters 0x01, 0x02, ... as in Noise/WireGuard. When this document writes (C', K) = KDF(C, ss), the first output updates the chaining key and the second is an AEAD key of AEAD-key length. mix_psk(C, H, PSK) computes KDF outputs (C', Htmp, K) from input (H || PSK), then sets H' = Hash(H || Htmp). The AEAD key K is used for the subsequent encrypted field (time or empty). Table 1: Informative chaining summary (Initiation through transport keys)

Step	Hash update	Chain-key update
0	H_0 = Hash(C_0 || label_2)	C_0 = Hash(label_1)
1	H_1 = Hash(H_0 || S_rpub)	C_1 = KDF(C_0, S_rpub)
2	H_2 = Hash(H_1 || E_ipub)	C_2 = KDF(C_1, E_ipub)
3	H_3 = Hash(H_2 || ct_1)	(C_3,K_1)=KDF(C_2, Hash(ct_1))
4	H_4 = Hash(H_3 || static)	C_4 = KDF(C_3, S_i^pub); then mix_psk -> C_5,H_5,K_2
5	H_6 = Hash(H_5 || time)	(after time AEAD)
6	H_7 = Hash(H_6 || ct_2)	C_6 = KDF(C_5, ct_2); C_7 = KDF(C_6, shk_2)
7	H_8 = Hash(H_7 || ct_3)	C_8 = KDF(C_7, Hash(ct_3)); mix_psk -> C_9,H_9,K_3
8	H_10 = Hash(H_9 || empty)	(C_10,K_4)=KDF(C_9, empty)
9	(transport)	(TK_i,TK_r)=KDF(C_10, "")

MAC1/MAC2 and Cookie Messages Let MsgPrefix be the message bytes excluding mac1 and mac2. Keys: mac1_key = BLAKE2s("mac1----" || S_r^pub) mac1 = BLAKE2s(key=mac1_key, data=MsgPrefix)[0:16] if Cookie available: mac2 = BLAKE2s(key=Cookie, data=MsgPrefix||mac1)[0:16] else: mac2 = 16 zero octets Under load, a Responder MAY ignore KEM processing and send Cookie Reply (Section 4.3.4). The Initiator decrypts the cookie and includes mac2 on retry. Receivers MUST verify mac1 (and mac2 when required) before expensive KEM work.

Implicit Authentication Model The Initiator proves knowledge bound to S_i by producing static = AEAD(Hash(S_i^pub)) under a key derived from ct_1 encapsulated to S_r. The Responder proves possession of S_r^priv by decapsulating ct_1 and later producing ct_3 to S_i^pub. Successful completion binds both long-term identities into TK_i/TK_r without transcript signatures.

Data Transport Protocol

Packet Format message TransportData { u8 type; u8 reserved_zero[3]; u32 key_idx; u64 counter; u8 ciphertext[]; } On the wire the UDP payload is exactly this structure. The outer UDP/IP headers are ordinary Internet headers toward the peer endpoint.

Packet Encryption When the virtual network interface captures a plaintext IP packet (Inner IP Packet) for transmission:

1. Select the sending key (TK_i on Initiator, TK_r on Responder) and remote key_idx.
2. Let counter be the next 64-bit sending counter (MUST NOT reuse under the same key).
3. For SM4-GCM: form a 12-octet IV as four zero octets followed by the eight little-endian octets of counter (IV bytes 4..11).
4. Encrypt with AEAD key = transport key, nonce/IV as above, plaintext = inner IP packet, AAD length = 0 (empty AAD).
5. Emit TransportData with ciphertext||tag.

Packet Decryption

1. Parse type/key_idx/counter; look up receiving key.
2. Anti-replay: maintain a sliding window; silently drop duplicates or out-of-window counters.
3. AEAD-decrypt with empty AAD; on failure silently drop.
4. Inject recovered inner IP packet into the local stack.

Application-Layer Fragmentation When a handshake message (after mac1/mac2 are attached) exceeds the maximum fragment payload size, implementations MUST fragment at the application layer rather than relying on IP fragmentation. Fragment header (8 octets, little-endian where noted): struct PqcFragHdr { u16 magic; u16 msg_id; u8 frag_index; u8 frag_total; u16 frag_len; }; The magic field MUST be 0x5051 (ASCII "PQ"), encoded little-endian. msg_id is a random reassembly identifier. frag_index is zero-based; frag_total is the number of fragments; frag_len is the number of payload octets in this fragment. Maximum fragment payload size is 1400 octets. The receiver reassembles fragments sharing (endpoint, msg_id) and passes the completed handshake buffer to the normal handshake parser (without the fragment header). Control encoding: frag_total = 0xFF and frag_index = 0xFF denotes a fragment ACK used by the sender for retransmission. Implementations SHOULD retransmit unacknowledged fragments with bounded retries. Fragmentation MUST be applied after mac1/mac2 computation so that MACs cover the original handshake message. Receivers MUST accept fragmented handshake messages for suites whose initiation or response exceeds typical path MTU (including the recommended mlkem512-mlkem768-sm4gcm-sm3 profile).

Cryptographic Algorithms

Asymmetric Algorithms Implementations of this specification's ML-KEM profiles MUST implement ML-KEM as specified in . Support for both ML-KEM-512 and ML-KEM-768 as Static_KEM and as Ephemeral_KEM is RECOMMENDED so that operators MAY choose any pairing. The profile mlkem512-mlkem768-sm4gcm-sm3 is RECOMMENDED. Digital signatures for out-of-band X.509 certificates: implementations that use the certificate path MUST support a quantum-resistant signature algorithm such as ML-DSA . Tunnel handshake authentication itself does not use signatures. Aigis-enc MAY appear in experimental builds as Static_KEM and/or Ephemeral_KEM using the same message layout and chaining rules; interoperable Aigis profiles are not yet normatively defined here.

Symmetric Algorithms For the recommended profile, AEAD MUST be SM4-GCM with 128-bit keys, 128-bit authentication tags, and 96-bit nonces, following the GCM construction as used with SM4 in national standards practice (see for SM4; GCM as referenced by related TLCP guidance ). Handshake AEAD nonce is 12 zero octets. Transport AEAD nonce/IV construction is defined in Section 5.2. Handshake AAD is the current transcript hash; transport AAD is empty.

Hash, KDF, and DoS MAC Suite Hash for the recommended profile MUST be SM3 . KDF is HKDF with HMAC-SM3 . mac1/mac2 and cookie key derivation use keyed BLAKE2s as in Section 4.6, even when the suite Hash is SM3. This separation follows the WireGuard DoS design retained by PQ-SecTunnel and is independent of the C/H hash chain.

Certificate Management

Certificate Format When certificates are used to distribute long-term KEM public keys, they MUST be X.509 v3 certificates.

Public Key Information The SubjectPublicKeyInfo field MUST carry the long-term PQC KEM public key. The AlgorithmIdentifier OID MUST identify the KEM algorithm (Appendix A).

OID Mapping Implementations MUST map SubjectPublicKeyInfo OIDs to the corresponding KEM implementation. Informative OID values under the Chinese national arc appear in Appendix A.

Certificate Validation Certificates MUST be distributed and validated out-of-band before handshake when the certificate path is used. Implementations MUST validate the signature chain against a configured trust anchor, check validity periods, and ensure the peer identity matches local policy. Raw public-key configuration without certificates remains permitted.

Security Considerations

Quantum Resistance Asymmetric handshake secrets are established with ML-KEM . Symmetric security for the recommended profile uses SM4-128 and SM3-256. Operators needing higher classical margins MAY select ML-KEM-768 for both roles.

Authentication and Key Pre-Distribution Implicit authentication requires authentic pre-distribution of long-term KEM public keys. Compromise or substitution of the preloaded peer public key enables MitM.

Forward Secrecy Session keys depend on shk_2 bound to the ephemeral private key E_i^priv, which MUST be destroyed after processing Handshake Response. Compromise of both long-term static private keys after the fact does not recover past TK_i/TK_r if E_i^priv was erased and the ephemeral KEM remains unbroken.

Replay and MitM Protection Handshake: the encrypted timestamp and transcript hash chain bind messages. Transport: the 64-bit counter with sliding-window anti-replay MUST be enforced.

Denial-of-Service Considerations mac1 provides a cheap filter keyed by the Responder public key. Under load, Cookie Reply enables mac2 checks before KEM decapsulation.

Static KEM Hash(ct) Mixing Mixing Hash(ct_1)/Hash(ct_3) instead of the raw static KEM shared secret is the current protocol rule and must be implemented for interoperability. It differs from the raw-shk rule used for ct_2. Changing this rule would be a breaking revision.

IANA Considerations

Service Name and Transport Protocol Port Number Registry IANA is requested to register PQ-SecTunnel in the "Service Name and Transport Protocol Port Number Registry".

• Service Name: pq-sectunnel
• Transport Protocol: UDP
• Port Number: TBD

PQ-SecTunnel Message Types Registry IANA is requested to create a registry "PQ-SecTunnel Message Types" with Specification Required registration policy. Initial values:

Value	Description	Reference
0	Invalid / reserved	this document
1	Handshake Initiation	this document
2	Handshake Response	this document
3	Key Confirmation	this document
4	Cookie Reply	this document
5	Transport Data	this document

OID Registrations OIDs under 1.2.156 used in Appendix A are outside IANA; no IANA action is requested.

References Normative References National Institute of Standards and Technology National Institute of Standards and Technology Standardization Administration of China (SAC) Standardization Administration of China (SAC) Standardization Administration of China (SAC) Informative References

OID Definitions Informative Object Identifiers under the Chinese national registration arc, as used by related certificate tooling. Only OIDs required by a deployment need be recognized. Table 2: PQC and GM/T OID Definitions

Object Identifier (OID)	Object Identifier Definition	备注
General Object Identifiers
1.2	International Organization for Standardization (ISO) Member Identifier
1.2.156	China
1.2.156.197	State Cryptography Administration (SCA)
1.2.156.10197	Cryptography Industry Standardization Technical Committee
1.2.156.10197.1	Cryptographic Algorithms
Block Cipher Algorithm Object Identifiers
1.2.156.10197.1.100	Block Cipher Algorithms
1.2.156.10197.1.102	SM1 Block Cipher Algorithm
1.2.156.10197.1.103	SSF33 Block Cipher Algorithm
1.2.156.10197.1.104	SM4 Block Cipher Algorithm
Stream Cipher Algorithm Object Identifiers
1.2.156.10197.1.200	Stream Cipher Algorithms
1.2.156.10197.1.201	Zuchongzhi Stream Cipher Algorithm
Public Key Cryptographic Algorithm Object Identifiers
1.2.156.10197.1.300	Public Key Cryptographic Algorithms
1.2.156.10197.1.301	SM2 Elliptic Curve Public Key Cryptographic Algorithm
1.2.156.10197.1.301.1	SM2-1 Digital Signature Algorithm
1.2.156.10197.1.301.2	SM2-2 Key Exchange Protocol
1.2.156.10197.1.301.3	SM2-3 Public Key Encryption Algorithm
1.2.156.10197.1.302	SM9 Identity-Based Cryptographic Algorithm
1.2.156.10197.1.302.1	SM9-1 Digital Signature Algorithm
1.2.156.10197.1.302.2	SM9-2 Key Exchange Protocol
1.2.156.10197.1.302.3	SM9-3 Key Encapsulation Mechanism and Public Key Encryption Algorithm
1.2.156.10197.1.303	Post-Quantum Key Encapsulation Algorithms	Post-Quantum
1.2.156.10197.1.303.1	ML-KEM-512 Key Encapsulation Algorithm	Post-Quantum
1.2.156.10197.1.303.2	ML-KEM-768 Key Encapsulation Algorithm	Post-Quantum
1.2.156.10197.1.303.3	ML-KEM-1024 Key Encapsulation Algorithm	Post-Quantum
1.2.156.10197.1.304	Post-Quantum Digital Signature Algorithms	Post-Quantum
1.2.156.10197.1.304.1	ML-DSA-44 Digital Signature Algorithm	Post-Quantum
1.2.156.10197.1.304.2	ML-DSA-65 Digital Signature Algorithm	Post-Quantum
1.2.156.10197.1.304.3	ML-DSA-87 Digital Signature Algorithm	Post-Quantum
Hash Algorithm Object Identifiers
1.2.156.10197.1.400	Hash Algorithms
1.2.156.10197.1.401	SM3 Cryptographic Hash Algorithm
1.2.156.10197.1.401.1	SM3 Cryptographic Hash Algorithm (No Key Used)
1.2.156.10197.1.401.2	SM3 Cryptographic Hash Algorithm (Key Used)
Combined Operation Algorithm Object Identifiers
1.2.156.10197.1.500	Combined Operation Mechanisms
1.2.156.10197.1.501	Signature Based on SM2 Algorithm and SM3 Algorithm
1.2.156.10197.1.504	Signature Based on RSA Algorithm and SM3 Algorithm
1.2.156.10197.1.505	Signature Based on ML-DSA Algorithm and SM3 Algorithm	Post-Quantum
1.2.156.10197.1.505.1	ML-DSA-44-with-SM3	Post-Quantum
1.2.156.10197.1.505.2	ML-DSA-65-with-SM3	Post-Quantum
1.2.156.10197.1.505.3	ML-DSA-87-with-SM3	Post-Quantum
1.2.156.10197.1.506	Signature Based on SM2, ML-DSA Algorithms and SM3 Algorithm	Post-Quantum
1.2.156.10197.1.506.1	ML-DSA-44-SM2-with-SM3	Post-Quantum
1.2.156.10197.1.506.2	ML-DSA-65-SM2-with-SM3	Post-Quantum
1.2.156.10197.1.506.3	ML-DSA-87-SM2-with-SM3	Post-Quantum
1.2.156.10197.1.507	Based on SM2 and ML-KEM Algorithms	Post-Quantum
1.2.156.10197.1.507.1	ML-KEM-512-SM2	Post-Quantum
1.2.156.10197.1.507.2	ML-KEM-768-SM2	Post-Quantum
1.2.156.10197.1.507.3	ML-KEM-1024-SM2	Post-Quantum
1.2.156.10197.1.508	Based on SM2 and ML-DSA Algorithms	Post-Quantum
1.2.156.10197.1.508.1	ML-DSA-44-SM2	Post-Quantum
1.2.156.10197.1.508.2	ML-DSA-65-SM2	Post-Quantum
1.2.156.10197.1.508.3	ML-DSA-87-SM2	Post-Quantum

Acknowledgments The authors thank contributors to the PQ-SecTunnel implementation and reviewers of earlier drafts. The handshake design builds on the Noise protocol framework and the WireGuard construction . Aigis-enc (and related lattice KEMs developed in the Chinese research community) are acknowledged as candidate additional KEM modules for the same tunnel framework; detailed Aigis profiles are deferred until implementation and interoperability work is complete. The designers of Kyber/ML-KEM and Dilithium/ML-DSA are likewise acknowledged.