Internet-Draft PQ-SecTunnel August 2026
Fan, et al. Expires 14 February 2027 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-pq-sectunnel-00
Published:
Intended Status:
Informational
Expires:
Authors:
K. Fan
Xidian University
R. Su
Xidian University
Y. Wang
Xidian University
J. Cheng
Xidian University

PQ-SecTunnel Protocol Specification

Abstract

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.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 14 February 2027.

▲

Table of Contents

1. 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.

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Additional terms used in this document:

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.

3. Protocol Overview

3.1. 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.

3.2. 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.

3.3. 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.

3.4. 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.

4. Key Agreement Protocol

4.1. 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.

4.2. 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_rpriv).

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).

  1. Both peers MUST use the same suite parameters.

4.3. 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):

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

4.3.1. 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).

4.3.2. 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).

4.3.3. 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];

}

4.4. 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)).

4.4.1. 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_rpub)

  5. (E_i^priv, E_i^pub) = EphemeralKEM.Gen()

  6. H_2 = Hash(H_1 || E_i^pub); C_2 = KDF(C_1, E_ipub)

  7. (ct_1, shk_1) = StaticKEM.Enc(S_rpub)

  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_ipub)

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

  1. time = AEAD.Enc(K_2, 0, t_now, H_5)

  2. H_6 = Hash(H_5 || time)

  3. mac1 / mac2 as in Section 4.6

  4. 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.

4.4.2. 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_ipub)

  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_ipub)

  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

4.4.3. Key Confirmation (Initiator)

  1. Verify mac1/mac2; on failure abort

  2. shk_2 = EphemeralKEM.Dec(E_i^priv, ct_2); destroy E_ipriv

  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)

4.4.4. 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)

4.5. Key Derivation and Chaining

KDF is Hugo Krawczyk's HKDF using HMAC with the suite Hash (HMAC-SM3 for the recommended profile) [RFC5869]. 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)

Table 2
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, "")

4.7. 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.

5. Data Transport Protocol

5.1. 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.

5.2. 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.

5.3. 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.

6. 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).

7. Cryptographic Algorithms

7.1. Asymmetric Algorithms

Implementations of this specification's ML-KEM profiles MUST implement ML-KEM as specified in [FIPS203]. 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 [FIPS204]. 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.

7.2. 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 [GBT32907] for SM4; GCM as referenced by related TLCP guidance [GB38636]).

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.

7.3. Hash, KDF, and DoS MAC

Suite Hash for the recommended profile MUST be SM3 [GBT32905]. KDF is HKDF with HMAC-SM3 [RFC5869].

mac1/mac2 and cookie key derivation use keyed BLAKE2s [RFC7693] 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.

8. Certificate Management

8.1. Certificate Format

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

8.2. 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).

8.3. OID Mapping

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

8.4. 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.

9. Security Considerations

9.1. Quantum Resistance

Asymmetric handshake secrets are established with ML-KEM [FIPS203]. 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.

9.2. 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.

9.3. 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.

9.4. 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.

9.5. 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.

9.6. 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.

10. IANA Considerations

10.1. 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

10.2. PQ-SecTunnel Message Types Registry

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

Table 3
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

10.3. OID Registrations

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

11. References

11.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC5869]
Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, , <https://www.rfc-editor.org/rfc/rfc5869>.
[RFC7693]
Saarinen, M.-J., Ed. and J.-P. Aumasson, "The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC)", RFC 7693, , <https://www.rfc-editor.org/rfc/rfc7693>.
[FIPS203]
National Institute of Standards and Technology, "Module-Lattice-Based Key-Encapsulation Mechanism Standard", FIPS 203, .
[FIPS204]
National Institute of Standards and Technology, "Module-Lattice-Based Digital Signature Standard", FIPS 204, .
[GBT32905]
Standardization Administration of China (SAC), "Information security technology - SM3 cryptographic hash algorithm", GB/T 32905, .
[GBT32907]
Standardization Administration of China (SAC), "Information security technology - SM4 block cipher algorithm", GB/T 32907, .
[GB38636]
Standardization Administration of China (SAC), "Information security technology - Transport Layer Cryptography Protocol (TLCP)", GB/T 38636, .

11.2. Informative References

[WIREGUARD]
Donenfeld, J.A., "WireGuard: Next Generation Kernel Network Tunnel", NDSS 2017, .

Appendix A. 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

Table 4
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 [WIREGUARD]. 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.

Authors' Addresses

Kai Fan
Xidian University
Xi'an
Shaanxi,
China
Ruidan Su
Xidian University
Xi'an
Shaanxi,
China
Yi Wang
Xidian University
Xi'an
Shaanxi,
China
Jiaqing Cheng
Xidian University
Xi'an
Shaanxi,
China