idnits 2.17.1 draft-yang-tls-tls13-sm-suites-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 04, 2020) is 1384 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS P. Yang 3 Internet-Draft Ant Technology 4 Intended status: Informational July 04, 2020 5 Expires: January 5, 2021 7 ShangMi (SM) Cipher Suites for Transport Layer Security (TLS) Protocol 8 Version 1.3 9 draft-yang-tls-tls13-sm-suites-04 11 Abstract 13 This document specifies a set of cipher suites for the Transport 14 Layer Security (TLS) protocol version 1.3 to support ShangMi (SM) 15 cryptographic algorithms. 17 The use of these cipher suites with TLSv1.3 is not endorsed by the 18 IETF. The SM cipher suites are becoming mandatory in China, and so 19 this document provides a description of how to use the SM cipher 20 suites with TLSv1.3 so that implementers can produce interworking 21 implementations. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 5, 2021. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. The SM Algorithms . . . . . . . . . . . . . . . . . . . . 3 59 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Supported Cipher Suites . . . . . . . . . . . . . . . . . . . 4 61 3. Cipher Suites Definitions . . . . . . . . . . . . . . . . . . 4 62 3.1. TLS Versions . . . . . . . . . . . . . . . . . . . . . . 4 63 3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 4 64 3.2.1. SM2 Signature Scheme . . . . . . . . . . . . . . . . 4 65 3.3. Key Exchange . . . . . . . . . . . . . . . . . . . . . . 6 66 3.3.1. Hello Messages . . . . . . . . . . . . . . . . . . . 6 67 3.3.2. CertificateRequest . . . . . . . . . . . . . . . . . 7 68 3.3.3. Certificate . . . . . . . . . . . . . . . . . . . . . 7 69 3.3.4. CertificateVerify . . . . . . . . . . . . . . . . . . 7 70 3.4. Key Scheduling . . . . . . . . . . . . . . . . . . . . . 7 71 3.5. Cipher . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 3.5.1. AEAD_SM4_GCM . . . . . . . . . . . . . . . . . . . . 8 73 3.5.2. AEAD_SM4_CCM . . . . . . . . . . . . . . . . . . . . 9 74 3.6. Hash . . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 77 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 6.1. Normative References . . . . . . . . . . . . . . . . . . 11 79 6.2. Informative References . . . . . . . . . . . . . . . . . 12 80 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 13 81 A.1. SM4-GCM Test Vectors . . . . . . . . . . . . . . . . . . 13 82 A.2. SM4-CCM Test Vectors . . . . . . . . . . . . . . . . . . 13 83 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 13 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 86 1. Introduction 88 This document describes two new cipher suites for the Transport Layer 89 Security (TLS) protocol version 1.3 (TLSv1.3, [RFC8446]). The new 90 cipher suites are (see also Section 2): 92 CipherSuite TLS_SM4_GCM_SM3 = { 0x00, 0xC6 }; 93 CipherSuite TLS_SM4_CCM_SM3 = { 0x00, 0xC7 }; 95 These new cipher suites contain several ShangMi (SM) cryptographic 96 algorithms that provide both authentication and confidentiality. For 97 a more detailed introduction to SM cryptographic algorithms, please 98 read Section 1.1. These cipher suites follow the TLSv1.3 99 requirements. Specifically, all the cipher suites mentioned in this 100 document use ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) as the 101 key exchange scheme and use SM4 in either GCM (Galois/Counter Mode) 102 mode or CCM (Counter with CBC-MAC) mode to meet the needs of TLSv1.3 103 to have an AEAD (Authenticated Encryption with Associated Data) 104 capable encryption algorithm. 106 For the details about how these new cipher suites negotiate shared 107 encryption keys and protect the record structure, please read 108 Section 3. 110 The cipher suites defined in this document are not recommended by the 111 IETF. The SM cipher suites are becoming mandatory in China, and so 112 this document provides a description of how to use the SM cipher 113 suites with TLSv1.3 so that implementers can produce interworking 114 implementations. 116 1.1. The SM Algorithms 118 The new cipher suites defined in this document use several different 119 SM cryptographic algorithms including SM2 for authentication, SM4 for 120 encryption and SM3 as the hash function. 122 SM2 is a set of elliptic curve based cryptographic algorithms 123 including digital signature, public key encryption and key exchange 124 scheme. In this document, only the SM2 digital signature algorithm 125 is involved, which has already been added to ISO/IEC 14888-3:2018 126 [ISO-SM2] (as well as in [GBT.32918.2-2016]). SM4 is a block cipher 127 defined in [GBT.32907-2016] and now is being standardized by ISO to 128 ISO/IEC 18033-3:2010 [ISO-SM4]. SM3 is a hash function which 129 produces an output of 256 bits. SM3 has already been accepted by ISO 130 in ISO/IEC 10118-3:2018 [ISO-SM3], and also been described by 131 [GBT.32905-2016]. 133 1.2. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 137 "OPTIONAL" in this document are to be interpreted as described in BCP 138 14 [RFC2119] [RFC8174] when, and only when, they appear in all 139 capitals, as shown here, and indicate requirement levels for 140 compliant TLSv1.3 implementations. 142 2. Supported Cipher Suites 144 The cipher suites defined here have the following identifiers: 146 CipherSuite TLS_SM4_GCM_SM3 = { 0x00, 0xC6 }; 147 CipherSuite TLS_SM4_CCM_SM3 = { 0x00, 0xC7 }; 149 To accomplish a TLSv1.3 handshake, additional objects have been 150 introduced along with the cipher suites as follows. 152 The SM2 signature algorithm and SM3 hash function used in the 153 Signature Algorithm extension defined in appendix-B.3.1.3 of 154 [RFC8446]: 156 SignatureScheme sm2sig_sm3 = { 0x0708 }; 158 The SM2 elliptic curve ID used in the Supported Groups extension 159 defined in appendix-B.3.1.4 of [RFC8446]: 161 NamedGroup curveSM2 = { 41 }; 163 3. Cipher Suites Definitions 165 3.1. TLS Versions 167 The new cpher suites defined in this document are only applicable to 168 TLSv1.3. Implementations of this document MUST NOT apply these 169 cipher suites to any older versions of TLS. 171 3.2. Authentication 173 3.2.1. SM2 Signature Scheme 175 All cipher suites defined in this document MUST use the SM2 signature 176 algorithm as the authentication method when doing a TLSv1.3 177 handshake. 179 The SM2 signature is defined in [ISO-SM2]. SM2 signature algorithm 180 is based on elliptic curves. SM2 signature algorithm uses a fixed 181 elliptic curve parameter set defined in [GBT.32918.5-2016]. This 182 curve has the name curveSM2 and has been assigned the value 41 as 183 shown in Section 4. Unlike other elliptic curve based public key 184 algorithms like ECDSA, SM2 MUST NOT select other elliptic curves. 185 But it is acceptable to write test cases that use other elliptic 186 curve parameter sets for SM2, take Annex F.14 of [ISO-SM2] as a 187 reference. 189 Implementations of the cipher suites defined in this document SHOULD 190 conform to what [GBT.32918.5-2016] requires, that is to say, the only 191 valid elliptic curve parameter for SM2 signature algorithm (a.k.a 192 curveSM2) is defined as follows: 194 curveSM2: a prime field of 256 bits 196 y^2 = x^3 + ax + b 198 p = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF 199 FFFFFFFF 00000000 FFFFFFFF FFFFFFFF 200 a = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF 201 FFFFFFFF 00000000 FFFFFFFF FFFFFFFC 202 b = 28E9FA9E 9D9F5E34 4D5A9E4B CF6509A7 203 F39789F5 15AB8F92 DDBCBD41 4D940E93 204 n = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF 205 7203DF6B 21C6052B 53BBF409 39D54123 206 Gx = 32C4AE2C 1F198119 5F990446 6A39C994 207 8FE30BBF F2660BE1 715A4589 334C74C7 208 Gy = BC3736A2 F4F6779C 59BDCEE3 6B692153 209 D0A9877C C62A4740 02DF32E5 2139F0A0 211 The SM2 signature algorithm requests an identifier value when 212 generating or verifying a signature. Implementations of this 213 document MUST use the following ASCII string value as the SM2 214 identifier when doing a TLSv1.3 key exchange: 216 TLSv1.3+GM+Cipher+Suite 218 Except if either a client or a server needs to verify the peer's SM2 219 certificate contained in the Certificate message, then the following 220 ASCII string value SHOULD be used as the SM2 identifier according to 221 [GMT.0009-2012]: 223 1234567812345678 225 Expressed as octets, this is: 227 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 228 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38 230 In practice, the SM2 identifier used in a certificate signature 231 depends on the CA who signs that certificate. CAs may choose values 232 other than the ones mentioned above. Implementations of this 233 document SHOULD confirm this information by themselves. 235 3.3. Key Exchange 237 3.3.1. Hello Messages 239 The new cipher suites defined in this document update the key 240 exchange information in the Hello messages. Implementations of these 241 new ciphers suites MUST conform to the new requirements. 243 3.3.1.1. ClientHello 245 A TLSv1.3 client MUST include the new cipher suites in its 246 'cipher_suites' array of the ClientHello structure defined in 247 Section 4.1.2 of [RFC8446]. 249 Other requirements on the extensions of ClientHello message are: 251 o For the supported_groups extension, 'curveSM2' MUST be included; 253 o For the signature_algorithms extension, 'sm2sig_sm3' MUST be 254 included; 256 o For the signature_algorithms_cert extension (if present), 257 'sm2sig_sm3' MUST be included; 259 o For the key_share extension, a KeyShareEntry with SM2 related 260 values MUST be added if the client wants to start a TLSv1.3 key 261 negotiation using SM cipher suites. 263 3.3.1.2. ServerHello 265 If a TLSv1.3 server receives a ClientHello message containing the new 266 cipher suites defined in this document, it MAY choose to use the new 267 cipher suites. If so, then the server MUST put one of the new cipher 268 suites defined in this document into its ServerHello's 269 'cipher_suites' array and eventually send it to the client side. 271 A TLSv1.3 server's choice of what cipher suite to use depends on the 272 configuration of the server. For instance, a TLSv1.3 server may be 273 configured to include the new cipher suites defined in this document, 274 or it may not be. Typical TLSv1.3 server applications also provide a 275 mechanism that configures the cipher suite preference at server side. 276 If a server is not configured to use the cipher suites defined in 277 this document, it SHOULD choose another cipher suite in the list that 278 the TLSv1.3 client provides; otherwise the server MUST abort the 279 handshake with an "illegal_parameter" alert. 281 The following extensions MUST conform to the new requirements: 283 o For the key_share extension, a KeyShareEntry with SM2 related 284 values MUST be added if the server wants to start a TLSv1.3 key 285 negotiation using SM cipher suites. 287 3.3.2. CertificateRequest 289 If a CertificateRequest message is sent by the server to require the 290 client to send its certificate for authentication purposes, the 291 following requirements MUST be fulfilled: 293 o The only valid signature algorithm present in 294 'signature_algorithms' extension MUST be 'sm2sig_sm3'. That is to 295 say, if server chooses to use an SM cipher suite, the signature 296 algorithm for client's certificate SHOULD only be SM2 and SM3 297 capable ones. 299 3.3.3. Certificate 301 When a server sends the Certificate message containing the server 302 certificate to the client side, several new rules are added that will 303 affect the certificate selection: 305 o The public key in the certificate MUST be a valid SM2 public key. 307 o The signature algorithm used by the CA to sign current certificate 308 MUST be 'sm2sig_sm3'. 310 o The certificate MUST be capable of signing, e.g., the 311 digitalSignature bit of X.509's Key Usage extension is set. 313 3.3.4. CertificateVerify 315 In the certificateVerify message, the signature algorithm MUST be 316 'sm2sig_sm3', indicating that the hash function MUST be SM3 and the 317 signature algorithm MUST be SM2. 319 3.4. Key Scheduling 321 As described in Section 1.1, SM2 is actually a set of cryptographic 322 algorithms including one key exchange protocol which defines methods 323 such as key derivation function, etc. In this document, SM2 key 324 exchange protocol is not introduced and SHALL NOT be used in the key 325 exchange steps defined in Section 3.3. Implementations of this 326 document MUST always conform to what TLSv1.3 [RFC8446] and its 327 successors require about the key derivation and related methods. 329 3.5. Cipher 331 The new cipher suites introduced in this document add two new AEAD 332 encryption algorithms, AEAD_SM4_GCM and AEAD_SM4_CCM, which stand for 333 SM4 cipher in Galois/Counter mode and SM4 cipher [GBT.32907-2016] in 334 Counter with CBC-MAC mode, respectively. 336 This section defines the AEAD_SM4_GCM and AEAD_SM4_CCM AEAD 337 algorithms in a style similar to what [RFC5116] used to define AEAD 338 ciphers based on AES cipher. 340 3.5.1. AEAD_SM4_GCM 342 The AEAD_SM4_GCM authenticated encryption algorithm works as 343 specified in [GCM], using SM4 as the block cipher, by providing the 344 key, nonce, plaintext, and associated data to that mode of operation. 345 An authentication tag conforming to the requirements of Section 5.2 346 of TLSv1.3 [RFC8446] MUST be constructed by the details in the TLS 347 record header. The additional data input that forms the 348 authentication tag MUST be the TLS record header. The AEAD_SM4_GCM 349 ciphertext is formed by appending the authentication tag provided as 350 an output to the GCM encryption operation to the ciphertext that is 351 output by that operation. AEAD_SM4_GCM has four inputs: an SM4 key, 352 an initialization vector (IV), a plaintext content, and optional 353 additional authenticated data (AAD). AEAD_SM4_GCM generates two 354 outputs: a ciphertext and message authentication code (also called an 355 authentication tag). To have a common set of terms for AEAD_SM4_GCM 356 and AEAD_SM4_CCM, the AEAD_SM4_GCM IV is referred to as a nonce in 357 the remainder of this document. A simple test vector of AEAD_SM4_GCM 358 and AEAD_SM4_CCM is given in Appendix A of this document. 360 The nonce is generated by the party performing the authenticated 361 encryption operation. 362 Within the scope of any authenticated-encryption key, the nonce value 363 MUST be unique. That is, the set of nonce values used with any given 364 key MUST NOT contain any duplicates. Using the same nonce for two 365 different messages encrypted with the same key destroys the security 366 properties of GCM mode. To generate the nonce, implementations of 367 this document MUST conform to TLSv1.3 (See [RFC8446], Section 5.3). 369 The input and output lengths are as follows: 371 the SM4 key length is 16 octets, 373 the max plaintext length is 2^36 - 31 octets, 375 the max AAD length is 2^61 - 1 octets, 377 the nonce length is 12 octets, 379 the authentication tag length is 16 octets, and 381 the max ciphertext length is 2^36 - 15 octets. 383 A security analysis of GCM is available in [MV04]. 385 3.5.2. AEAD_SM4_CCM 387 The AEAD_SM4_CCM authenticated encryption algorithm works as 388 specified in [CCM], using SM4 as the block cipher. AEAD_SM4_CCM has 389 four inputs: an SM4 key, a nonce, a plaintext, and optional 390 additional authenticated data (AAD). AEAD_SM4_CCM generates two 391 outputs: a ciphertext and a message authentication code (also called 392 an authentication tag). The formatting and counter generation 393 functions are as specified in Appendix A of [CCM], and the values of 394 the parameters identified in that appendix are as follows: 396 the nonce length n is 12, 398 the tag length t is 16, and 400 the value of q is 3. 402 An authentication tag is also used in AEAD_SM4_CCM. The generation 403 of the authentication tag MUST conform to TLSv1.3 (See [RFC8446], 404 Section 5.2). The AEAD_SM4_CCM ciphertext is formed by appending the 405 authentication tag provided as an output to the CCM encryption 406 operation to the ciphertext that is output by that operation. The 407 input and output lengths are as follows: 409 the SM4 key length is 16 octets, 411 the max plaintext length is 2^24 - 1 octets, 413 the max AAD length is 2^64 - 1 octets, and 415 the max ciphertext length is 2^24 + 15 octets. 417 To generate the nonce, implementations of this document MUST conform 418 to TLSv1.3 (See [RFC8446], Section 5.3). 420 A security analysis of CCM is available in [J02]. 422 3.6. Hash 424 SM3 is defined by ISO in [ISO-SM3]. During a TLSv1.3 handshake with 425 SM cipher suites, the hash function is REQUIRED to be SM3. 426 Implementations MUST use SM3 for digest, key derivation, Transcript- 427 Hash and other purposes during a TLSv1.3 key exchange process. 429 4. IANA Considerations 431 IANA has assigned the values {0x00, 0xC6} and {0x00, 0xC7} with the 432 names TLS_SM4_GCM_SM3, TLS_SM4_CCM_SM3, to the "TLS Cipher Suite" 433 registry with this document as reference: 435 +-----------+-----------------+---------+-------------+-----------+ 436 | Value | Description | DTLS-OK | Recommended | Reference | 437 +-----------+-----------------+---------+-------------+-----------+ 438 | 0x00,0xC6 | TLS_SM4_GCM_SM3 | No | No | this RFC | 439 | | | | | | 440 | 0x00,0xC7 | TLS_SM4_CCM_SM3 | No | No | this RFC | 441 +-----------+-----------------+---------+-------------+-----------+ 443 IANA has assigned the value 0x0708 with the name 'sm2sig_sm3', to the 444 "TLS SignatureScheme" registry: 446 +--------+-------------+-------------+-----------+ 447 | Value | Description | Recommended | Reference | 448 +--------+-------------+-------------+-----------+ 449 | 0x0708 | sm2sig_sm3 | No | this RFC | 450 +--------+-------------+-------------+-----------+ 452 IANA has assigned the value 41 with the name 'curveSM2', to the "TLS 453 Supported Groups" registry: 455 +-------+-------------+---------+-------------+-----------+ 456 | Value | Description | DTLS-OK | Recommended | Reference | 457 +-------+-------------+---------+-------------+-----------+ 458 | 41 | curveSM2 | No | No | this RFC | 459 +-------+-------------+---------+-------------+-----------+ 461 5. Security Considerations 463 At the time of writing, there are no known weak keys for SM 464 cryptographic algorithms: SM2, SM3 and SM4, and no security issues 465 have been found for these algorithms. 467 6. References 469 6.1. Normative References 471 [CCM] Dworkin, M, ., "NIST Special Publication 800-38C: The CCM 472 Mode for Authentication and Confidentiality", May 2004, 473 . 476 [GCM] Dworkin, M, ., "NIST Special Publication 800-38D: 477 Recommendation for Block Cipher Modes of Operation: 478 Galois/Counter Mode (GCM) and GMAC.", November 2007, 479 . 482 [ISO-SM2] International Organization for Standardization, "IT 483 Security techniques -- Digital signatures with appendix -- 484 Part 3: Discrete logarithm based mechanisms", ISO ISO/IEC 485 14888-3:2018, November 2018, 486 . 488 [ISO-SM3] International Organization for Standardization, "IT 489 Security techniques -- Hash-functions -- Part 3: Dedicated 490 hash-functions", ISO ISO/IEC 10118-3:2018, October 2018, 491 . 493 [ISO-SM4] International Organization for Standardization, "IT 494 Security techniques -- Encryption algorithms -- Part 3: 495 Block ciphers", ISO ISO/IEC 18038-3:2010, December 2010, 496 . 498 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 499 Requirement Levels", BCP 14, RFC 2119, 500 DOI 10.17487/RFC2119, March 1997, 501 . 503 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 504 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 505 . 507 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 508 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 509 May 2017, . 511 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 512 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 513 . 515 6.2. Informative References 517 [GBT.32905-2016] 518 Standardization Administration of China, "Information 519 security technology --- SM3 cryptographic hash algorithm", 520 GB/T 32905-2016, March 2017, . 523 [GBT.32907-2016] 524 Standardization Administration of China, "Information 525 security technology --- SM4 block cipher algorithm", GB/ 526 T 32907-2016, March 2017, . 529 [GBT.32918.2-2016] 530 Standardization Administration of China, "Information 531 security technology --- Public key cryptographic algorithm 532 SM2 based on elliptic curves --- Part 2: Digital signature 533 algorithm", GB/T 32918.2-2016, March 2017, 534 . 537 [GBT.32918.5-2016] 538 Standardization Administration of China, "Information 539 security technology --- Public key cryptographic algorithm 540 SM2 based on elliptic curves --- Part 5: Parameter 541 definition", GB/T 32918.5-2016, March 2017, 542 . 545 [GMT.0009-2012] 546 State Cryptography Administration of China, "SM2 547 cryptography algorithm application specification", GM/ 548 T 0009-2016, November 2012, . 551 [J02] Jonsson, J, ., "On the Security of CTR + CBC-MAC", 2002, < 552 http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/propo 553 sedmodes/ccm/ccm-ad1.pdf>. 555 [MV04] Viega, McGrew,., "The Security and Performance of the 556 Galois/Counter Mode (GCM)", December 2004, 557 . 559 Appendix A. Test Vectors 561 All values are in hexadecimal and are in network byte order (big 562 endian). 564 A.1. SM4-GCM Test Vectors 566 Initialization Vector: 00001234567800000000ABCD 567 Key: 0123456789ABCDEFFEDCBA9876543210 568 Plaintext: AAAAAAAAAAAAAAAABBBBBBBBBBBBBBBB 569 CCCCCCCCCCCCCCCCDDDDDDDDDDDDDDDD 570 EEEEEEEEEEEEEEEEFFFFFFFFFFFFFFFF 571 EEEEEEEEEEEEEEEEAAAAAAAAAAAAAAAA 572 Associated Data: FEEDFACEDEADBEEFFEEDFACEDEADBEEFABADDAD2 573 CipherText: 17F399F08C67D5EE19D0DC9969C4BB7D 574 5FD46FD3756489069157B282BB200735 575 D82710CA5C22F0CCFA7CBF93D496AC15 576 A56834CBCF98C397B4024A2691233B8D 577 Authentication Tag: 83DE3541E4C2B58177E065A9BF7B62EC 579 A.2. SM4-CCM Test Vectors 581 Initialization Vector: 00001234567800000000ABCD 582 Key: 0123456789ABCDEFFEDCBA9876543210 583 Plaintext: AAAAAAAAAAAAAAAABBBBBBBBBBBBBBBB 584 CCCCCCCCCCCCCCCCDDDDDDDDDDDDDDDD 585 EEEEEEEEEEEEEEEEFFFFFFFFFFFFFFFF 586 EEEEEEEEEEEEEEEEAAAAAAAAAAAAAAAA 587 Associated Data: FEEDFACEDEADBEEFFEEDFACEDEADBEEFABADDAD2 588 CipherText: 48AF93501FA62ADBCD414CCE6034D895 589 DDA1BF8F132F042098661572E7483094 590 FD12E518CE062C98ACEE28D95DF4416B 591 ED31A2F04476C18BB40C84A74B97DC5B 592 Authentication Tag: 16842D4FA186F56AB33256971FA110F4 594 Appendix B. Contributors 596 Wuqiong Pan 597 Ant Technology 598 wuqiong.pwq@antfin.com 600 Qin Long 601 Ant Technology 602 zhuolong.lq@antfin.com 604 Kepeng Li 605 Ant Technology 606 kepeng.lkp@antfin.com 607 Ke Zeng 608 Ant Technology 609 william.zk@antfin.com 611 Han Xiao 612 Ant Technology 613 han.xiao@antfin.com 615 Zhi Guan 616 Peking University 617 guan@pku.edu.cn 619 Author's Address 621 Paul Yang 622 Ant Technology 623 No. 77 Xueyuan Road 624 Hangzhou 310000 625 China 627 Phone: +86-571-2688-8888 628 Fax: +86-571-8643-2811 629 Email: kaishen.yy@antfin.com