The new cipher suites defined in this document are only applicable to TLS 1.3. Implementations of this document MUST NOT
apply these cipher suites to any older versions of TLS.
The Chinese government requires the use of the SM2 signature algorithm. This section specifies the use of the SM2 signature algorithm as the authentication method for a TLS 1.3 handshake.
The SM2 signature algorithm is defined in [ISO-SM2
]. The SM2 signature algorithm is based on elliptic curves. The SM2 signature algorithm uses a fixed elliptic curve parameter set defined in [GBT.32918.5-2017
]. This curve is named "curveSM2" and has been assigned the value 41, as shown in Section 2
. Unlike other public key algorithms based on elliptic curve cryptography like the Elliptic Curve Digital Signature Algorithm (ECDSA), SM2 MUST NOT
select other elliptic curves. But it is acceptable to write test cases that use other elliptic curve parameter sets for SM2; see Annex F.14 of [ISO-SM2
] as a reference.
Implementations of the signature scheme and key exchange mechanism defined in this document MUST
conform to what [GBT.32918.5-2017
] requires; that is to say, the only valid elliptic curve parameter set for the SM2 signature algorithm (a.k.a. curveSM2) is defined as follows:
A prime field of 256 bits.
+ ax + b
p = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF 00000000 FFFFFFFF FFFFFFFF
a = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF
FFFFFFFF 00000000 FFFFFFFF FFFFFFFC
b = 28E9FA9E 9D9F5E34 4D5A9E4B CF6509A7
F39789F5 15AB8F92 DDBCBD41 4D940E93
n = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF
7203DF6B 21C6052B 53BBF409 39D54123
Gx = 32C4AE2C 1F198119 5F990446 6A39C994
8FE30BBF F2660BE1 715A4589 334C74C7
Gy = BC3736A2 F4F6779C 59BDCEE3 6B692153
D0A9877C C62A4740 02DF32E5 2139F0A0
The SM2 signature algorithm requests an identifier value when generating or verifying a signature. In all uses except when a client of a server needs to verify a peer's SM2 certificate in the Certificate message, an implementation of this document MUST
use the following ASCII string value as the SM2 identifier when doing a TLS 1.3 key exchange:
If either a client or a server needs to verify the peer's SM2 certificate contained in the Certificate message, then the following ASCII string value MUST
be used as the SM2 identifier according to [GMT.0009-2012
Expressed as octets, this is:
0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38,
0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38
In practice, the SM2 identifier used in a certificate signature depends on the certificate authority (CA) who signs that certificate. CAs may choose values other than the ones mentioned above. Implementations of this document SHOULD
confirm this information by themselves.
The use of the algorithms defined by this document is negotiated during the TLS handshake with information exchanged in the Hello messages.
To use the cipher suites defined by this document, a TLS 1.3 client includes the new cipher suites in the "cipher_suites" array of the ClientHello structure defined in Section 4.1.2
of RFC 8446
Other requirements of this TLS 1.3 profile on the extensions of ClientHello message are as follows:
For the supported_groups extension, "curveSM2" MUST be included.
For the signature_algorithms extension, "sm2sig_sm3" MUST be included.
For the signature_algorithms_cert extension (if present), "sm2sig_sm3" MUST be included.
For the key_share extension, a KeyShareEntry for the "curveSM2" group MUST be included.
If a TLS 1.3 server receives a ClientHello message containing the algorithms defined in this document, it MAY
choose to use them. If so, then the server MUST
put one of the new cipher suites defined in this document into its ServerHello's "cipher_suites" array and eventually send it to the client side.
A TLS 1.3 server's choice of what cipher suite to use depends on the configuration of the server. For instance, a TLS 1.3 server may or not be configured to include the new cipher suites defined in this document. Typical TLS 1.3 server applications also provide a mechanism that configures the cipher suite preference on the server side. If a server is not configured to use the cipher suites defined in this document, it SHOULD
choose another cipher suite in the list that the TLS 1.3 client provides; otherwise, the server MUST
abort the handshake with an "illegal_parameter" alert.
The following extension MUST
conform to the new requirements:
For the key_share extension, a KeyShareEntry with SM2-related values MUST be added if the server wants to conform to this profile.
If a CertificateRequest message is sent by the server to require the client to send its certificate for authentication purposes, for conformance to this profile, the following is REQUIRED
The only valid signature algorithm present in "signature_algorithms" extension MUST be "sm2sig_sm3". That is to say, if the server chooses to conform to this profile, the signature algorithm for the client's certificate MUST use the SM2/SM3 procedure specified by this document.
When a server sends the Certificate message containing the server certificate to the client side, several new rules are added that will affect the certificate selection:
The public key in the certificate MUST be a valid SM2 public key.
The signature algorithm used by the CA to sign the current certificate MUST be "sm2sig_sm3".
The certificate MUST be capable of signing; e.g., the digitalSignature bit of X.509's Key Usage extension is set.
In the CertificateVerify message, the signature algorithm MUST
be "sm2sig_sm3", indicating that the hash function MUST
be SM3 and the signature algorithm MUST
As described in Section 1.1
, SM2 is actually a set of cryptographic algorithms, including one key exchange protocol that defines methods such as key derivation function, etc. This document does not define an SM2 key exchange protocol, and an SM2 key exchange protocol SHALL NOT
be used in the key exchange steps defined in Section 3.3
. Implementations of this document MUST
always conform to what TLS 1.3 [RFC 8446
] and its successors require regarding the key derivation and related methods.
The new cipher suites introduced in this document add two new AEAD encryption algorithms, AEAD_SM4_GCM and AEAD_SM4_CCM, which stand for SM4 cipher in Galois/Counter mode and SM4 cipher [GBT.32907-2016
] in Counter with CBC-MAC mode, respectively. The hash function for both cipher suites is SM3 ([ISO-SM3
This section defines the AEAD_SM4_GCM and AEAD_SM4_CCM AEAD algorithms in a style similar to what [RFC 5116
] used to define AEAD ciphers based on the AES cipher.
The AEAD_SM4_GCM authenticated encryption algorithm works as specified in [GCM
], using SM4 as the block cipher, by providing the key, nonce, plaintext, and associated data to that mode of operation. An authentication tag conforming to the requirements of TLS 1.3 as specified in Section 5.2
of RFC 8446 MUST
be constructed using the details in the TLS record header. The additional data input that forms the authentication tag MUST
be the TLS record header. The AEAD_SM4_GCM ciphertext is formed by appending the authentication tag provided as an output to the GCM encryption operation to the ciphertext that is output by that operation. AEAD_SM4_GCM has four inputs: an SM4 key, an initialization vector (IV), a plaintext content, and optional additional authenticated data (AAD). AEAD_SM4_GCM generates two outputs: a ciphertext and message authentication code (also called an authentication tag). To have a common set of terms for AEAD_SM4_GCM and AEAD_SM4_CCM, the AEAD_SM4_GCM IV is referred to as a nonce in the remainder of this document. A simple test vector of AEAD_SM4_GCM and AEAD_SM4_CCM is given in Appendix A
of this document.
The nonce is generated by the party performing the authenticated encryption operation. Within the scope of any authenticated encryption key, the nonce value MUST
be unique. That is, the set of nonce values used with any given key MUST NOT
contain any duplicates. Using the same nonce for two different messages encrypted with the same key destroys the security properties of GCM mode. To generate the nonce, implementations of this document MUST
conform to TLS 1.3 (see RFC 8446
, Section 5.3
The input and output lengths are as follows:
The SM4 key length is 16 octets.
The max plaintext length is 236 - 31 octets.
The max AAD length is 261 - 1 octets.
The nonce length is 12 octets.
The authentication tag length is 16 octets.
The max ciphertext length is 236 - 15 octets.
A security analysis of GCM is available in [MV04
The AEAD_SM4_CCM authenticated encryption algorithm works as specified in [CCM
] using SM4 as the block cipher. AEAD_SM4_CCM has four inputs: an SM4 key, a nonce, a plaintext, and optional additional authenticated data (AAD). AEAD_SM4_CCM generates two outputs: a ciphertext and a message authentication code (also called an authentication tag). The formatting and counter generation functions are as specified in Appendix A of [CCM
], and the values of the parameters identified in that appendix are as follows:
The nonce length n is 12.
The tag length t is 16.
The value of q is 3.
An authentication tag is also used in AEAD_SM4_CCM. The generation of the authentication tag MUST
conform to TLS 1.3 (See RFC 8446
, Section 5.2
). The AEAD_SM4_CCM ciphertext is formed by appending the authentication tag provided as an output to the CCM encryption operation to the ciphertext that is output by that operation. The input and output lengths are as follows:
The SM4 key length is 16 octets.
The max plaintext length is 224 - 1 octets.
The max AAD length is 264 - 1 octets.
The max ciphertext length is 224 + 15 octets.
To generate the nonce, implementations of this document MUST
conform to TLS 1.3 (see RFC 8446
, Section 5.3
A security analysis of CCM is available in [J02