TLS
Independent Submission P. Yang
Internet-Draft
Request for Comments: 8998 Ant Group
Intended status:
Category: Informational September 27, 2020
Expires: March 31, 2021
ISSN: 2070-1721
ShangMi (SM) Cipher Suites for Transport Layer Security (TLS) Protocol
Version TLS 1.3
draft-yang-tls-tls13-sm-suites-06
Abstract
This document specifies how to use the ShangMi (SM) cryptographic
algorithms with Transport Layer Security (TLS) protocol version 1.3.
The use of these algorithms with TLSv1.3 TLS 1.3 is not endorsed by the IETF.
The SM algorithms are becoming mandatory in China, and so this document
provides a description of how to use the SM algorithms with
TLSv1.3 TLS 1.3
and specifies a profile of TLSv1.3 TLS 1.3 so that implementers can produce
interworking implementations.
Status of This Memo
This Internet-Draft document is submitted in full conformance with not an Internet Standards Track specification; it is
published for informational purposes.
This is a contribution to the
provisions RFC Series, independently of BCP 78 any other
RFC stream. The RFC Editor has chosen to publish this document at
its discretion and BCP 79.
Internet-Drafts makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are working documents not candidates for any level of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list Standard;
see Section 2 of RFC 7841.
Information about the current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum status of six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 March 31, 2021.
https://www.rfc-editor.org/info/rfc8998.
Copyright Notice
Copyright (c) 2020 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. The SM Algorithms . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Algorithm Identifiers . . . . . . . . . . . . . . . . . . . . 4
3. Algorithm Definitions . . . . . . . . . . . . . . . . . . . . 4
3.1. TLS Versions . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 4
3.2.1. SM2 Signature Scheme . . . . . . . . . . . . . . . . 4
3.3. Key Exchange . . . . . . . . . . . . . . . . . . . . . . 6
3.3.1. Hello Messages . . . . . . . . . . . . . . . . . . . 6
3.3.2. CertificateRequest . . . . . . . . . . . . . . . . . 7
3.3.3. Certificate . . . . . . . . . . . . . . . . . . . . . 7
3.3.4. CertificateVerify . . . . . . . . . . . . . . . . . . 7
3.4. Key Scheduling . . . . . . . . . . . . . . . . . . . . . 7
3.5. Cipher . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.5.1. AEAD_SM4_GCM . . . . . . . . . . . . . . . . . . . . 8
3.5.2. AEAD_SM4_CCM . . . . . . . . . . . . . . . . . . . . 9
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Normative References . . . . . . . . . . . . . . . . . . 11
6.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 13
A.1. SM4-GCM Test Vectors . . . . . . . . . . . . . . . . . . 13
A.2. SM4-CCM Test Vectors . . . . . . . . . . . . . . . . . . 13
Appendix B.
Contributors . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
This document describes two new cipher suites, a signature algorithm, algorithm
and a key-exchange key exchange mechanism for the Transport Layer Security (TLS)
protocol version 1.3 (TLSv1.3, [RFC8446]). (TLS 1.3) ([RFC8446]). These all utilize
several ShangMi (SM) cryptographic algorithms to fulfil fulfill the
authentication and confidentiality requirements of TLS 1.3. The new
cipher suites are as follows (see also Section 2):
CipherSuite TLS_SM4_GCM_SM3 = { 0x00, 0xC6 };
CipherSuite TLS_SM4_CCM_SM3 = { 0x00, 0xC7 };
For a more detailed introduction to SM cryptographic algorithms,
please read see Section 1.1. These cipher suites follow the TLSv1.3 TLS 1.3
requirements. Specifically, all the cipher suites use SM4 in either
GCM (Galois/Counter Mode)
Galois/Counter (GCM) mode or CCM (Counter Counter with CBC-MAC) CBC-MAC (CCM) mode to meet
the needs of TLSv1.3 TLS 1.3 to have an AEAD (Authenticated encryption algorithm that is
Authenticated Encryption with Associated Data) capable encryption algorithm. Data (AEAD) capable. The
key exchange mechanism utilizes ECDHE (Elliptic Elliptic Curve Diffie-Hellman Ephemeral)
Ephemeral (ECDHE) over the SM2 elliptic curve, and the signature
algorithm combines the SM3 hash function and the SM2 elliptic curve
signature scheme.
For the details about how these mechanisms negotiate shared encryption
keys, authenticate the peer(s), and protect the record structure,
please read see Section 3.
The cipher suites, signature algorithm, and key exchange mechanism
defined in this document are not recommended by the IETF. The SM
algorithms are becoming mandatory in China, and so this document provides
a description of how to use them with TLSv1.3 TLS 1.3 and specifies a profile
of TLS 1.3 so that implementers can produce interworking
implementations.
1.1. The SM Algorithms
Several different SM cryptographic algorithms are used to integrate
with TLS 1.3, including SM2 for authentication, SM4 for encryption encryption,
and SM3 as the hash function.
SM2 is a set of elliptic curve based cryptographic algorithms based on elliptic curve
cryptography, including a digital signature, public key encryption
and key exchange scheme. In this document, only the SM2 digital
signature algorithm and basic key exchange scheme are involved, which
have already been added to ISO/IEC 14888-3:2018 [ISO-SM2] (as well as in
to [GBT.32918.2-2016]). SM4 is a block cipher defined in
[GBT.32907-2016] and now is being standardized by ISO to ISO/IEC
18033-3:2010 [ISO-SM4]. SM3 is a hash function which that produces an
output of 256 bits. SM3 has already been accepted by ISO in ISO/IEC
10118-3:2018 [ISO-SM3], [ISO-SM3] and has also been described by
[GBT.32905-2016].
1.2. Terminology
Although this document is not an IETF Standards Track publication it
adopts the conventions for normative language to provide clarity of
instructions to the implementer, and to indicate requirement levels
for compliant TLSv1.3 implementations.
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.
Although this document is not an IETF Standards Track publication, it
adopts the conventions for normative language to provide clarity of
instruction to the implementer and to indicate requirement levels for
compliant TLS 1.3 implementations.
2. Algorithm Identifiers
The cipher suites defined here have the following identifiers:
CipherSuite TLS_SM4_GCM_SM3 = { 0x00, 0xC6 };
CipherSuite TLS_SM4_CCM_SM3 = { 0x00, 0xC7 };
To accomplish a TLSv1.3 TLS 1.3 handshake, additional objects have been
introduced along with the cipher suites as follows:
o
* The combination of the SM2 signature algorithm and SM3 hash
function used in the Signature Algorithm extension is defined in appendix-
Appendix B.3.1.3 of [RFC8446]:
SignatureScheme sm2sig_sm3 = { 0x0708 };
o
* The SM2 elliptic curve ID used in the Supported Groups extension
is defined in appendix-B.3.1.4 Appendix B.3.1.4 of [RFC8446]:
NamedGroup curveSM2 = { 41 };
3. Algorithm Definitions
3.1. TLS Versions
The new cipher suites defined in this document are only applicable to
TLSv1.3.
TLS 1.3. Implementations of this document MUST NOT apply these
cipher suites to any older versions of TLS.
3.2. Authentication
3.2.1. SM2 Signature Scheme
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 TLSv1.3 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-2016].
[GBT.32918.5-2017]. This curve has the name curveSM2 is named "curveSM2" and has been
assigned the value 41 41, as shown in Section 2. Unlike other elliptic
curve based public
key algorithms based on elliptic curve cryptography like ECDSA, 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, take 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-2016]
requires, [GBT.32918.5-2017]
requires; that is to say, the only valid elliptic curve parameter set
for the SM2 signature algorithm (a.k.a (a.k.a. curveSM2) is defined as
follows:
curveSM2: a A prime field of 256 bits
y^2 bits.
y^(2) = x^3 x^(3) + 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
TLSv1.3 TLS
1.3 key exchange:
TLSv1.3+GM+Cipher+Suite
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]:
1234567812345678
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 CA 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.
3.3. Key Exchange
3.3.1. Hello Messages
The use of the algorithms defined by this document is negotiated
during the TLS handshake with information exchanged in the Hello
messages.
3.3.1.1. ClientHello
To use the cipher suites defined by this document, a TLSv1.3 TLS 1.3 client
includes the new cipher suites in the 'cipher_suites' "cipher_suites" array of the
ClientHello structure defined in Section 4.1.2 of [RFC8446].
Other requirements of this TLSv1.3 TLS 1.3 profile on the extensions of
ClientHello message are:
o are as follows:
* For the supported_groups extension, 'curveSM2' "curveSM2" MUST be included;
o included.
* For the signature_algorithms extension, 'sm2sig_sm3' "sm2sig_sm3" MUST be
included;
o
included.
* For the signature_algorithms_cert extension (if present),
'sm2sig_sm3'
"sm2sig_sm3" MUST be included;
o included.
* For the key_share extension, a KeyShareEntry for the 'curveSM2' "curveSM2"
group MUST be included included.
3.3.1.2. ServerHello
If a TLSv1.3 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' "cipher_suites" array and
eventually send it to the client side.
A TLSv1.3 TLS 1.3 server's choice of what cipher suite to use depends on the
configuration of the server. For instance, a TLSv1.3 TLS 1.3 server may or
not be configured to include the new cipher suites defined in this document,
or it may not be.
document. Typical TLSv1.3 TLS 1.3 server applications also provide a
mechanism that configures the cipher suite preference at 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 TLSv1.3 TLS 1.3 client provides; otherwise otherwise, the server MUST abort
the handshake with an "illegal_parameter" alert.
The following extensions extension MUST conform to the new requirements:
o
* For the key_share extension, a KeyShareEntry with SM2 related SM2-related
values MUST be added if the server wants to conform to this
profile.
3.3.2. CertificateRequest
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, it the following is REQUIRED that:
o REQUIRED:
* The only valid signature algorithm present in
'signature_algorithms'
"signature_algorithms" extension MUST be 'sm2sig_sm3'. "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 SM2/
SM3 procedure specified by this document.
3.3.3. Certificate
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:
o
* The public key in the certificate MUST be a valid SM2 public key.
o
* The signature algorithm used by the CA to sign the current
certificate MUST be 'sm2sig_sm3'.
o "sm2sig_sm3".
* The certificate MUST be capable of signing, signing; e.g., the
digitalSignature bit of X.509's Key Usage extension is set.
3.3.4. CertificateVerify
In the CertificateVerify message, the signature algorithm MUST be
'sm2sig_sm3',
"sm2sig_sm3", indicating that the hash function MUST be SM3 and the
signature algorithm MUST be SM2.
3.4. Key Scheduling
As described in Section 1.1, SM2 is actually a set of cryptographic
algorithms
algorithms, including one key exchange protocol which 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 TLSv1.3 TLS 1.3
[RFC8446] and its successors require about regarding the key derivation and
related methods.
3.5. Cipher
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 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 [RFC5116] used to define AEAD
ciphers based on the AES cipher.
3.5.1. AEAD_SM4_GCM
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 TLSv1.3 [RFC8446] 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- 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 TLSv1.3 TLS 1.3
(see [RFC8446], Section 5.3).
The input and output lengths are as follows:
the
The SM4 key length is 16 octets,
the octets.
The max plaintext length is 2^36 2^(36) - 31 octets,
the octets.
The max AAD length is 2^61 2^(61) - 1 octets,
the octets.
The nonce length is 12 octets,
the octets.
The authentication tag length is 16 octets, and
the octets.
The max ciphertext length is 2^36 2^(36) - 15 octets.
A security analysis of GCM is available in [MV04].
3.5.2. AEAD_SM4_CCM
The AEAD_SM4_CCM authenticated encryption algorithm works as
specified in [CCM], [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
The nonce length n is 12,
the 12.
The tag length t is 16, and
the 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 TLSv1.3 TLS 1.3 (See [RFC8446],
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
The SM4 key length is 16 octets,
the octets.
The max plaintext length is 2^24 2^(24) - 1 octets,
the octets.
The max AAD length is 2^64 2^(64) - 1 octets, and
the octets.
The max ciphertext length is 2^24 2^(24) + 15 octets.
To generate the nonce, implementations of this document MUST conform
to TLSv1.3 TLS 1.3 (see [RFC8446], Section 5.3).
A security analysis of CCM is available in [J02].
4. IANA Considerations
IANA has assigned the values {0x00, 0xC6} {0x00,0xC6} and {0x00, 0xC7} {0x00,0xC7} with the
names TLS_SM4_GCM_SM3, TLS_SM4_CCM_SM3, "TLS_SM4_GCM_SM3" and "TLS_SM4_CCM_SM3" to the "TLS Cipher Suite"
Suites" registry with this document as reference:
+-----------+-----------------+---------+-------------+-----------+
+===========+=================+=========+=============+===========+
| Value | Description | DTLS-OK | Recommended | Reference |
+-----------+-----------------+---------+-------------+-----------+
+===========+=================+=========+=============+===========+
| 0x00,0xC6 | TLS_SM4_GCM_SM3 | No | No | this RFC 8998 |
| | | | | |
+-----------+-----------------+---------+-------------+-----------+
| 0x00,0xC7 | TLS_SM4_CCM_SM3 | No | No | this RFC 8998 |
+-----------+-----------------+---------+-------------+-----------+
Table 1
IANA has assigned the value 0x0708 with the name 'sm2sig_sm3', "sm2sig_sm3" to the
"TLS SignatureScheme" registry:
+--------+-------------+-------------+-----------+
+========+=============+=============+===========+
| Value | Description | Recommended | Reference |
+--------+-------------+-------------+-----------+
+========+=============+=============+===========+
| 0x0708 | sm2sig_sm3 | No | this RFC 8998 |
+--------+-------------+-------------+-----------+
Table 2
IANA has assigned the value 41 with the name 'curveSM2', "curveSM2" to the "TLS
Supported Groups" registry:
+-------+-------------+---------+-------------+-----------+
+=======+=============+=========+=============+===========+
| Value | Description | DTLS-OK | Recommended | Reference |
+-------+-------------+---------+-------------+-----------+
+=======+=============+=========+=============+===========+
| 41 | curveSM2 | No | No | this RFC 8998 |
+-------+-------------+---------+-------------+-----------+
Table 3
5. Security Considerations
At the time of writing, there are no known weak keys for SM
cryptographic algorithms: algorithms SM2, SM3 and SM4, and no security issues
have been found for these algorithms.
A security analysis of GCM is available in [MV04].
A security analysis of CCM is available in [J02].
6. References
6.1. Normative References
[CCM] Dworkin, M, ., "NIST Special Publication 800-38C: The M., "Recommendation for Block Cipher Modes of
Operation: the CCM Mode for Authentication and
Confidentiality", Special Publication 800-38C,
DOI 10.6028/NIST.SP.800-38C, May 2004,
<http://csrc.nist.gov/publications/nistpubs/800-38C/
SP800-38C.pdf>.
[GCM] Dworkin, M, ., "NIST Special Publication 800-38D:
Recommendation M., "Recommendation for Block Cipher Modes of
Operation: Galois/Counter Mode (GCM) and GMAC.", GMAC", Special
Publication 800-38D, DOI 10.6028/NIST.SP.800-38D, November
2007, <http://csrc.nist.gov/publications/nistpubs/800-38D/
SP-800-38D.pdf>.
[ISO-SM2] International Organization for Standardization, "IT
Security techniques -- Digital signatures with appendix --
Part 3: Discrete logarithm based mechanisms", ISO ISO/IEC ISO/
IEC 14888-3:2018, November 2018,
<https://www.iso.org/standard/76382.html>.
[ISO-SM3] International Organization for Standardization, "IT
Security techniques -- Hash-functions -- Part 3: Dedicated
hash-functions", ISO ISO/IEC 10118-3:2018, October 2018,
<https://www.iso.org/standard/67116.html>.
[ISO-SM4] International Organization for Standardization, "IT
"Information technology -- Security techniques --
Encryption algorithms -- Part 3: Block ciphers", ISO ISO/IEC ISO/
IEC 18033-3:2010, December 2010,
<https://www.iso.org/standard/54531.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/info/rfc5116>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
6.2. Informative References
[GBT.32905-2016]
Standardization Administration of China, "Information
security technology --- SM3 cryptographic hash algorithm",
GB/T 32905-2016, March 2017, <http://www.gmbz.org.cn/
upload/2018-07-24/1532401392982079739.pdf>.
[GBT.32907-2016]
Standardization Administration of the People's Republic of
China, "Information security technology --- -- SM4 block
cipher algorithm", GB/
T GB/T 32907-2016, March 2017,
<http://www.gmbz.org.cn/
upload/2018-04-04/1522788048733065051.pdf>.
[GBT.32918.2-2016]
Standardization Administration of the People's Republic of
China, "Information security technology --- Public key
cryptographic algorithm SM2 based on elliptic curves ---
Part 2: Digital signature algorithm", GB/T 32918.2-2016,
March 2017, <http://www.gmbz.org.cn/
upload/2018-07-24/1532401673138056311.pdf>.
[GBT.32918.5-2016]
[GBT.32918.5-2017]
Standardization Administration of the People's Republic of
China, "Information security technology --- Public key
cryptographic algorithm SM2 based on elliptic curves ---
Part 5: Parameter definition", GB/T 32918.5-2016, March 32918.5-2017, December
2017, <http://www.gmbz.org.cn/
upload/2018-07-24/1532401863206085511.pdf>.
[GMT.0009-2012]
State Cryptography Administration of China, Administration, "SM2 cryptography
algorithm application specification", GM/
T 0009-2016, GM/T 0009-2012,
November 2012, <http://www.gmbz.org.cn/main/
viewfile/2018011001400692565.html>.
[J02] Jonsson, J, ., J., "On the Security of CTR + CBC-MAC", 2002, <
http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/propo
sedmodes/ccm/ccm-ad1.pdf>.
DOI 10.1007/3-540-36492-7_7, February 2003,
<https://link.springer.com/
chapter/10.1007%2F3-540-36492-7_7>.
[MV04] McGrew, D. and J. Viega, McGrew,., "The Security and Performance of
the Galois/Counter Mode (GCM)", of Operation",
DOI 10.1007/978-3-540-30556-9_27, December 2004,
<http://eprint.iacr.org/2004/193>.
Appendix A. Test Vectors
All values are in hexadecimal and are in network byte order (big
endian).
A.1. SM4-GCM Test Vectors
Initialization Vector: 00001234567800000000ABCD
Key: 0123456789ABCDEFFEDCBA9876543210
Plaintext: AAAAAAAAAAAAAAAABBBBBBBBBBBBBBBB
CCCCCCCCCCCCCCCCDDDDDDDDDDDDDDDD
EEEEEEEEEEEEEEEEFFFFFFFFFFFFFFFF
EEEEEEEEEEEEEEEEAAAAAAAAAAAAAAAA
Associated Data: FEEDFACEDEADBEEFFEEDFACEDEADBEEFABADDAD2
CipherText: 17F399F08C67D5EE19D0DC9969C4BB7D
5FD46FD3756489069157B282BB200735
D82710CA5C22F0CCFA7CBF93D496AC15
A56834CBCF98C397B4024A2691233B8D
Authentication Tag: 83DE3541E4C2B58177E065A9BF7B62EC
A.2. SM4-CCM Test Vectors
Initialization Vector: 00001234567800000000ABCD
Key: 0123456789ABCDEFFEDCBA9876543210
Plaintext: AAAAAAAAAAAAAAAABBBBBBBBBBBBBBBB
CCCCCCCCCCCCCCCCDDDDDDDDDDDDDDDD
EEEEEEEEEEEEEEEEFFFFFFFFFFFFFFFF
EEEEEEEEEEEEEEEEAAAAAAAAAAAAAAAA
Associated Data: FEEDFACEDEADBEEFFEEDFACEDEADBEEFABADDAD2
CipherText: 48AF93501FA62ADBCD414CCE6034D895
DDA1BF8F132F042098661572E7483094
FD12E518CE062C98ACEE28D95DF4416B
ED31A2F04476C18BB40C84A74B97DC5B
Authentication Tag: 16842D4FA186F56AB33256971FA110F4
Appendix B.
Contributors
Qin Long
Ant Group
Email: zhuolong.lq@antfin.com
Kepeng Li
Ant Group
Email: kepeng.lkp@antfin.com
Ke Zeng
Ant Group
Email: william.zk@antfin.com
Han Xiao
Ant Group
Email: han.xiao@antfin.com
Zhi Guan
Peking University
Email: guan@pku.edu.cn
Author's Address
Paul Yang
Ant Group
No. 77 Xueyuan Road
Hangzhou
310000
China
Phone: +86-571-2688-8888
Fax: +86-571-8643-2811
Email: kaishen.yy@antfin.com