Key encapsulation method, system applied to HPKE protocol and HPKE encrypted communication method

Abstract

The application relates to a key encapsulation method, system and HPKE encryption communication method applied to an HPKE protocol and belongs to the technical field of encryption communication. The method comprises the following steps: a key encapsulation party performs an encapsulation operation, the encapsulation operation comprises the following steps: an SM2 temporary key pair is generated, the SM2 temporary key pair comprises a temporary private key and a temporary public key; an SM2-ECDH algorithm is used to calculate a first shared point by using the temporary private key and an SM2 public key of a receiving party; the temporary public key, the SM2 public key of the receiving party and the first shared point are spliced to generate input data; and then, an SM3 hash message authentication code function is used for key extraction to generate a shared key. According to the scheme, the key exchange protocol in the SM2 standard which must be interacted by both parties is innovatively combined with the SM3-HMAC, is transformed into a one-way non-interactive KEM primitive conforming to the HPKE standard, the interactive national secret algorithm is converted into a non-interactive standard interface, the core semantic gap problem is solved, and the national secret algorithm can be seamlessly integrated into the HPKE protocol in the standard KEM interface.

Description

Technical Field

[0001] This application belongs to the field of encrypted communication technology, and in particular relates to a key encapsulation method, system and HPKE encrypted communication method applied to the HPKE protocol. Background Technology

[0002] With the rapid development of modern encryption protocols (such as Hybrid Public-Key Encryption (HPKE), RFC 9180) and group communication security architectures (such as Message Layer Security (MLS)), non-interactive key negotiation based on Key Encapsulation Mechanism (KEM) has become a core technology for building efficient and secure communication systems. Existing international standards, such as RFC 9180, have defined a series of elliptic curve-based KEM implementations, such as DHKEM / P256 (based on the NIST P-256 curve) and DHKEM / X25519. These schemes rely on internationally accepted cryptographic algorithms and hash functions (such as the SHA series) to ensure security and interoperability. However, these standardized KEM implementations do not cover Chinese commercial cryptographic algorithms (national cryptographic algorithms), making it impossible to directly apply these advanced protocol frameworks in security systems that need to comply with national cryptographic standards, thus creating a technological ecosystem barrier.

[0003] In the national commercial cryptography standard system, the SM2 public-key cryptography algorithm (GM / T 0003-2012) is a core component, encompassing digital signatures, key exchange, and public-key encryption. Although the SM2 standard defines a complete elliptic curve-based key exchange protocol, it is designed as an interactive two-round communication mode, requiring both parties to generate temporary key pairs and exchange information. This interactive mode presents a significant semantic gap compared to the unidirectional, non-interactive KEM interface required by modern protocols such as HPKE. Specifically, standard SM2 key exchange cannot be directly adapted to KEM operations where the sender can independently encapsulate and output a shared key using only the receiver's static public key. This fundamental protocol difference makes it difficult to seamlessly integrate the SM2 algorithm into protocol stacks such as HPKE and MLS that rely on non-interactive key exchange.

[0004] Therefore, existing technologies face obstacles in efficiently, securely, and in a standardized manner integrating the national cryptographic algorithm SM2 into modern non-interactive encryption protocols. An innovative approach is urgently needed to address issues such as protocol adaptation, key derivation input construction, and standardized identification. Summary of the Invention

[0005] This application aims to at least partially address one of the technical problems in related technologies. To this end, the key encapsulation method, system, and HPKE encrypted communication method provided in this application, by combining the national cryptographic SM2 algorithm with the SM3 hash message authentication code function, transforms the original SM2 key exchange protocol, which required two-way interaction, into a one-way non-interactive key encapsulation mechanism conforming to the HPKE standard. This resolves the semantic gap between the SM2 algorithm and modern non-interactive encryption protocols, achieving seamless integration of the national cryptographic algorithm into protocols such as HPKE.

[0006] To achieve the above objectives, in a first aspect, this application provides a key encapsulation method for the HPKE protocol, comprising a key encapsulation party performing an encapsulation operation, the encapsulation operation including:

[0007] S11. Generate an SM2 temporary key pair, wherein the SM2 temporary key pair includes a temporary private key and a temporary public key; S12. Using the temporary private key and the recipient's SM2 public key, execute the SM2 elliptic curve Diffie-Hellman key exchange algorithm to calculate the first shared point; S13. The temporary public key, the receiver's SM2 public key, and the first sharing point are concatenated in a first predetermined order to generate input data; S14. Based on the input data, extract the key using the SM3 hash message authentication code function to generate a shared key; The output of the encapsulation operation includes the temporary public key and the shared key.

[0008] Preferably, the input data is constructed by concatenating the temporary public key, the receiver's SM2 public key, and the first sharing point in sequence; The temporary public key and the recipient's SM2 public key are in 65-byte uncompressed format conforming to the SEC 1 standard, the first shared point is 64 bytes, and the total length of the input data is 194 bytes.

[0009] Preferably, the key encapsulation method further includes a key decapsulating party performing a decapsulation operation, the decapsulation operation including: S21. Receive the temporary public key from the key encapsulation party; S22. Using the local SM2 private key and the temporary public key, execute the SM2 elliptic curve Diffie-Hellman key exchange algorithm to calculate the second shared point; S23. Based on the temporary public key, the local SM2 public key, and the second sharing point, concatenate them in the first predetermined order to construct identical input data; S24. Based on the input data, use the SM3 hash message authentication code function to extract the key and generate the same shared key.

[0010] Preferably, before the key encapsulating party performs the encapsulation operation or the key decapsulating party performs the decapsulation operation, a format conversion step is further included: Convert the Jacobian coordinate representation of the SM2 public key used for internal calculations into a 65-byte uncompressed byte sequence conforming to the SEC 1 standard; or, The received 65-byte uncompressed SM2 public key conforming to the SEC 1 standard is parsed, verified, and converted into the Jacobian coordinate representation used for internal calculations.

[0011] Preferably, the steps for verifying the SM2 public key include: Verify that the byte sequence length of the SM2 public key is 65 bytes and that the first byte is a predetermined value representing an uncompressed point; And / or, verify that the point corresponding to the SM2 public key is located on the SM2 elliptic curve.

[0012] Preferably, the key encapsulation method further includes: Define an identifier for identifying components of the national cryptographic algorithm, wherein the identifier is within a preset private numerical range; The identifier includes at least a first identifier for identifying the SM2-based key encapsulation mechanism, a second identifier for identifying the SM3-based key derivation function, and a third identifier for identifying the SM4-GCM authentication encryption algorithm.

[0013] Preferably, the private value range is 0xFF00 to 0xFFFF; the first identifier is 0xFF03, the second identifier is 0xFF02, and the third identifier is 0xFF01.

[0014] Secondly, this application provides a key encapsulation system for the HPKE protocol, comprising: The key negotiation module is used to implement the encapsulation and / or decapsulation operations in any of the key encapsulation methods described above, so as to generate a shared key; The key derivation module is used to implement key extraction based on the SM3 hash message authentication code function, so as to derive the encryption key and initial vector from the shared key; The format conversion module adopts a zero-copy format conversion mechanism to directly convert the internal data structure of the underlying national cryptographic algorithm library into the standard data format required by the HPKE protocol. The cryptographic suite management module is used to store and manage the identifiers of the components of the national cryptographic algorithm.

[0015] Thirdly, this application provides an HPKE encrypted communication method based on Chinese national cryptographic algorithms, including a key negotiation phase and a data transmission phase: During the key negotiation phase, the sender and receiver negotiate a shared key using the key encapsulation method based on the SM2 algorithm described above. Based on the shared key, the encryption key and initialization vector are derived using the SM3 hash message authentication code function; During the data transmission phase, the sender uses the encryption key, the initialization vector, and the SM4-GCM authentication encryption algorithm to encrypt the plaintext data to obtain ciphertext and then sends it. The receiver uses the encryption key, the initialization vector, and the SM4-GCM authentication encryption algorithm to decrypt the received ciphertext to obtain plaintext data.

[0016] Preferably, during the key negotiation phase, the sender performs the encapsulation operation, generates and sends the encapsulation output, which includes a temporary public key; The receiver receives the encapsulated output and performs a decapsulation operation to obtain the shared key; The sender and the receiver use the same context information to derive the same encryption key and initialization vector based on the shared key.

[0017] Preferably, the HPKE encrypted communication method further includes: providing a unified cryptographic service interface for the national cryptographic algorithm through a cryptographic suite management module, wherein the cryptographic suite management module is used to manage the identifiers of the national cryptographic algorithm components.

[0018] Based on the above technical solutions, it can be seen that the key encapsulation method, system, and HPKE encrypted communication method applied to the HPKE protocol of this application have at least one of the following beneficial effects compared with the prior art: 1. This application innovatively combines SM2-ECDH (SM2 Elliptic Curve Diffie-Hellman Key Exchange Algorithm) and SM3-HMAC (SM3 Hash Message Authentication Code Function) to transform the key exchange protocol in the SM2 standard, which requires two-way interaction, into a one-way non-interactive KEM primitive conforming to the HPKE standard. This fundamental transformation enables the Chinese national cryptographic algorithm to be seamlessly integrated into the HPKE protocol for the first time using a standard KEM interface, filling the technical gap of the Chinese national cryptographic algorithm in non-interactive key distribution scenarios and solving the long-standing problem of protocol semantic adaptation.

[0019] 2. This application defines a specific concatenation method for a 194-byte KDF input. This construct concatenates the temporary public key, the recipient's public key, and the shared key in a fixed order. Its technical value lies in: ① Security level: By binding the public keys of both parties, an identity binding attribute is provided for the shared key, effectively preventing identity confusion and unknown key sharing attacks; including the temporary public key ensures that each encapsulation is different. ② Engineering level: This construct strictly specifies that the public key adopts the SEC 1 standard 65-byte uncompressed format, enabling different implementations to generate completely identical input data, thereby deriving a consistent shared key and ensuring cross-platform and cross-implementation determinism and interoperability.

[0020] 3. This application not only solves the algorithm adaptation problem but also provides a complete integration solution. At the implementation layer, a format conversion and verification mechanism that balances efficiency and security is designed to ensure efficient internal computation and secure conversion to external standard formats. At the protocol layer, a national cryptographic algorithm identifier system located in the private numerical range (0xFF00-0xFFFF) is innovatively defined to avoid conflicts with the standard suites registered with IANA, laying a standardized foundation for HPKE / MLS protocol recognition and invocation of national cryptographic suites. This forms an end-to-end solution from underlying algorithm construction and middleware implementation to upper-layer protocol identification. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a flowchart of the SM2 DHKEM encapsulation process in a key encapsulation method for the HPKE protocol provided in this application; Figure 2 This is a flowchart of the SM2 DHKEM desealing process in a key encapsulation method for the HPKE protocol provided in this application; Figure 3 This is the flowchart of the SM3-HKDF key derivation provided in this application; Figure 4 This is a flowchart of the SM2 public key format conversion provided in this application; Figure 5 This is the HPKE context workflow diagram provided in this application. Detailed Implementation

[0023] To facilitate understanding of this application, a more complete description will be provided below. However, this application can be implemented in many different forms and is not limited to the embodiments described herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of the disclosure of this application.

[0024] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0025] In this application, terms such as "preferred," "better," "more suitable," and "ideal" are merely used to describe implementation methods or embodiments that achieve better results, and should be understood not to limit the scope of protection of this application.

[0026] In this application, terms such as "further," "even more," and "particularly" are used for descriptive purposes and to indicate differences in content, but should not be construed as limiting the scope of protection of this application.

[0027] In this application, "optionally," "optionally," and "optional" mean that something is optional, that is, it means that it is selected from either "with" or "without." If there are multiple "optional" entries in a technical solution, unless otherwise specified, and there are no contradictions or mutual constraints, each "optional" entry shall be independent.

[0028] In this application, the terms "first aspect," "second aspect," "third aspect," and "fourth aspect," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or quantity, nor should they be construed as implicitly indicating the importance or quantity of the indicated technical features. Moreover, "first," "second," "third," and "fourth," etc., serve only a non-exhaustive enumeration purpose and should be understood not to constitute a closed limitation on quantity.

[0029] In this application, the technical features described in an open-ended manner include both closed technical solutions consisting of the listed features and open technical solutions that include the listed features.

[0030] This application aims to address the semantic gap between the SM2 algorithm and the HPKE standard by providing a key encapsulation method for the HPKE protocol, enabling SM2 to be seamlessly integrated into modern encryption protocols such as HPKE / MLS.

[0031] Specifically, this application aims to solve the following three core technical problems: (1) Protocol semantic adaptation problem The key exchange protocol defined by the SM2 national cryptographic standard (GM / T 0003-2012) is a two-way interactive protocol, requiring both communicating parties to generate and exchange temporary keys. In contrast, the KEM required by the HPKE standard (RFC9180) is a one-way non-interactive protocol, where the sender only needs the receiver's public key to complete key encapsulation. The two protocols have fundamentally different interaction modes, necessitating innovative construction methods to achieve semantic adaptation.

[0032] (2) Key Derivation Input Construction Problem The HPKE standard requires that the shared key output by KEM has a key confirmation attribute, meaning that the derivation process of the shared key needs to be bound to the identity information of both communicating parties. How to construct secure key derivation inputs to prevent identity confusion attacks and unknown key sharing attacks is the key problem this invention aims to solve.

[0033] (3) Standardized identification and format compatibility issues Existing HPKE / MLS implementations use IANA-registered cipher suite identifiers, but lack identifier definitions for Chinese national cryptographic algorithms. Furthermore, the data formats used internally by the Chinese national cryptographic algorithm library (such as Jacobian coordinates) are incompatible with the byte sequence format required by the HPKE standard, necessitating the establishment of a standardized identifier system and format conversion mechanism.

[0034] The technical concept of this invention lies in resolving the structural contradiction between the Chinese national cryptographic algorithm SM2 and modern non-interactive key encapsulation mechanisms (KEM), thereby achieving seamless integration of the Chinese national cryptographic algorithm into mainstream international protocols such as HPKE and MLS. The existing SM2 key exchange protocol is an interactive design, which has a fundamental semantic gap with the unidirectional KEM interface required by the HPKE standard, making it unsuitable for direct application in efficient unidirectional key distribution scenarios.

[0035] To address this, this invention proposes an innovative adaptation framework. Its core lies in constructing a one-way key encapsulation primitive through the creative application of the SM2 algorithm. Specifically, the sender generates a temporary key pair and performs an elliptic curve Diffie-Hellman (ECDH) calculation using its private key and the receiver's public key to obtain a shared secret point. The key innovative step is to concatenate the sender's temporary public key, the receiver's static public key, and this shared point in a specific order as the sole input to the key derivation function (KDF). This construction not only completes the semantic transformation from interactive to non-interactive but also endows the shared key with authentication attributes by binding both parties' public keys to the key derivation process, fundamentally preventing man-in-the-middle attacks.

[0036] Simultaneously, this invention incorporates a standardized national cryptographic algorithm identifier system and an efficient data format conversion mechanism, resolving the challenges of missing protocol layer identifiers and incompatible implementation layer formats. Ultimately, this concept forms a complete national cryptographic protocol chain, from SM2 one-way key encapsulation and SM3 key derivation to SM4 authentication and encryption, providing a core technological foundation for building an independent and controllable secure communication system (such as the national cryptographic MLS) that conforms to international protocol paradigms.

[0037] Regarding the HPKE standard and key encapsulation mechanism: HPKE (Hybrid Public Key Encryption) is an IETF standard, RFC 9180, designed to provide a unified and efficient public key encryption interface for modern encryption protocols. The core of this standard is the Key Encapsulation Mechanism (KEM), whose interface definition is as follows: Encapsulation operation: KEM.Encap(pk) -> (shared_secret, enc); Uncapping operation: KEM.Decap(enc, _sk) -> shared_secret; In this structure, pk is the receiver's public key, sk is the receiver's private key, enc is the encapsulated output (usually the sender's temporary public key), and shared_secret is the shared symmetric key negotiated by both parties. HPKE, due to its clear structure and high security, has been widely adopted by modern security protocols such as MLS (Messaging Layer Security, RFC 9420), providing fundamental support for end-to-end encrypted communication.

[0038] Regarding commercial cryptographic algorithms in China, according to the Cryptography Law of the People's Republic of China, critical information infrastructure should use commercial cryptography for protection. The commercial cryptographic algorithms released by the State Cryptography Administration include: SM2: Elliptic curve cryptography algorithm (GM / T0003-2012), 256-bit security strength; SM3: Cryptographic Hash Algorithm (GM / T0004-2012), outputs a 256-bit hash value; SM4: Block Cipher Algorithm (GM / T0002-2012), 128-bit Key and Block Length.

[0039] Existing MLS protocol implementations have the following technical problems: (1) Does not support national cryptographic algorithms Without SM2 / SM3 / SM4 cryptographic suites, it is impossible to meet the compliance requirements of key sectors such as government and finance in China.

[0040] (2) Security risks of cross-language FFI (Foreign Function Interface) calls.

[0041] Mobile devices often need to call cryptographic libraries implemented in C. Cross-language FFI calls face the following challenges: inconsistent memory layout: mapping issues between C structures and high-level language types; ownership management: it is unclear which side allocates and releases memory; lack of type safety: C language has no type checking, which can easily lead to pointer errors. For example, fixed-size array parameters in C language can easily be incorrectly mapped to require both pointer and length parameters, resulting in parameter alignment errors and memory access violations.

[0042] Therefore, this application innovatively combines SM2-ECDH and SM3-HMAC to transform the key exchange protocol in the SM2 standard, which requires two-way interaction, into a one-way non-interactive KEM primitive conforming to the HPKE standard. This converts the interactive national cryptographic protocol into a non-interactive standard interface, solving the core semantic gap problem and enabling the national cryptographic algorithm to be seamlessly integrated into modern protocols such as HPKE and MLS through a standard KEM interface.

[0043] This application provides a key encapsulation method based on the SM2 algorithm, including a key encapsulation party performing an encapsulation operation, which includes: S11. Generate an SM2 temporary key pair, which includes a temporary private key and a temporary public key; S12. Using the temporary private key and the recipient's SM2 public key, execute the SM2 elliptic curve Diffie-Hellman key exchange algorithm (i.e., SM2-ECDH algorithm) to calculate the first shared point; S13. Concatenate the temporary public key, the recipient's SM2 public key, and the first shared point in a first predetermined order to generate input data; S14. Based on the input data, extract the key using the SM3 hash message authentication code function (i.e., the SM3-HMAC key derivation function) to generate a shared key; The output of the encapsulation operation includes a temporary public key and a shared key.

[0044] This embodiment establishes a basic framework for key encapsulation based on Chinese national cryptographic algorithms (SM2, SM3), providing a novel key negotiation and distribution method that does not rely on international standard algorithms (such as RSA-KEM, ECDH-KEM). By introducing ephemeral key pairs, forward security is achieved (even if the receiver's private key is leaked long-term, past session keys will not be cracked). The method has clear steps, separating key negotiation from key extraction, enhancing the modularity and security of the design.

[0045] In one possible implementation, the input data is constructed by concatenating the temporary public key, the receiver's SM2 public key, and the first shared point in sequence. The temporary public key and the recipient's SM2 public key are in 65-byte uncompressed format conforming to the SEC 1 standard. The first shared point is 64 bytes, and the total length of the input data is 194 bytes.

[0046] This embodiment specifies the exact format and length of the input data, particularly stipulating the use of a public key representation in a 65-byte uncompressed format conforming to the SEC 1 standard. This ensures the determinism and interoperability of the algorithm implementation; different devices and software libraries can generate identical shared keys as long as they follow this format, effectively avoiding negotiation failures caused by differences in data encoding or serialization.

[0047] In one possible implementation, the key encapsulation method further includes the key decapsulating party performing a decapsulation operation, which includes: S21. Receive the temporary public key from the key encapsulator; S22. Using the local SM2 private key and temporary public key, execute the SM2 elliptic curve Diffie-Hellman key exchange algorithm to calculate the second shared point; S23. Based on the temporary public key, the local SM2 public key, and the second sharing point, the data is concatenated in a first predetermined order to construct identical input data. S24. Based on the input data, use the SM3 hash message authentication code function to extract the key and generate the same shared key.

[0048] The desealing operation in this embodiment forms a complete closed loop with the encapsulation operation. It clarifies that the desealing party does not need additional secret information; it can independently calculate the same shared key using only its own long-term private key and the received temporary public key. This verifies the correctness and symmetry of the encapsulation mechanism and fully defines the protocol process for key negotiation between the two parties.

[0049] like Figure 1 and Figure 2 The diagrams shown are the encapsulation flowchart and decapsulation flowchart of the SM2 DHKEM of this application, respectively. SM2DHKEM is a key encapsulation mechanism based on SM2 elliptic curves. It combines the SM2-ECDH (Elliptic Curve Diffie-HellIman) algorithm with the SM3-KDF (Key Derivation Function) to implement key encapsulation primitives that conform to the HPKE (Hybrid Public Key Encryption) standard.

[0050] Encapping stage: Obtain the receiver's public key remote_key, generate a temporary SM2 key pair (ephemeral_sk, ephemeral_pk), use the temporary private key ephemeral_sk and the receiver's public key remote_key to perform the ECDH algorithm to calculate the shared point Z, use the temporary public key ephemeral_pk as the encapsulation output enc, construct a KDF with the input of concatenation of ephemeral_pk||remote_key||Z, and use SM3-HMAC to extract and generate the shared key shared_secret.

[0051] Decapping phase: The receiver uses the local private key local_sk and the encapsulated output enc to perform the ECDH algorithm to calculate the same shared point Z, construct the same KDF input enc||local_pk||Z, and use SM3-HMAC to extract and generate the same shared key shared_secret.

[0052] In one possible implementation, the key encapsulation method also includes: Define an identifier for identifying components of the national cryptographic algorithm. The identifier is within a preset private value range. The identifier includes at least a first identifier for identifying the SM2-based key encapsulation mechanism, a second identifier for identifying the SM3-based key derivation function, and a third identifier for identifying the SM4-GCM authentication encryption algorithm.

[0053] In one possible implementation, the private value range is 0xFF00 to 0xFFFF; the first identifier is 0xFF03, the second identifier is 0xFF02, and the third identifier is 0xFF01.

[0054] This avoids conflicts with standard suites registered with IANA, laying a standardized foundation for the HPKE / MLS protocol to identify and invoke national cryptographic suites.

[0055] In one possible implementation, the key derivation mechanism is based on the SM3 hash algorithm, including: During the extraction phase, the SM3-HMAC algorithm is used to calculate the pseudo-random key using the salt value and input key material as input. During the expansion phase, the SM3-KDF algorithm is used to concatenate the pseudo-random key with context information as input to derive output key material of a specified length.

[0056] A key derivation mechanism based on the SM3 hash algorithm (SM3-HKDF) is adopted, thus combining the internationally accepted HKDF framework with the national standard SM3 algorithm. In the Extract phase, SM3-HMAC is used to ensure pseudo-randomness, while in the Expand phase, the national standard SM3-KDF algorithm is employed. This ensures that the key derivation process conforms to both internationally accepted security models and meets the compliance requirements of national commercial cryptography, providing a secure and reliable key derivation service for upper-layer protocols.

[0057] like Figure 3 The diagram shown is a flowchart of the SM3-HKDF key derivation process provided in this application. Figure 3 This paper elucidates a two-step process for key derivation based on the SM3 algorithm, following the paradigm of "extract first, then expand." Its working principle combines the strong pseudo-randomness of HMAC-SM3 with the expansion capability of SM3-KDF. The workflow is clearly divided into two stages: In the Extract stage, a fixed-length pseudo-random key (PRK) is extracted using SM3-HMAC calculations based on the salt value and input key material (IKM). Then, in the Expand stage, this PRK is concatenated with specific information (Info) and fed as input to the SM3 key derivation function (KDF) conforming to the national standard GM / T0004-2012, generating the final output key material (OKM) of the required length.

[0058] Specifically, the PRK calculation in the Extract phase includes: SM3 is used as the underlying hash function, key K is the salt value, and message M is the input key material; If the length of K exceeds 64 bytes, then SM3 hash compression is used first; Calculate ipad=K XOR 0x36 (repeated to 64 bytes), calculate opad=K XOR 0x5C (repeated to 64 bytes), where XOR is the exclusive OR operation, and ipad and opad are two derived keys; The output HMAC=SM3(opad ||SM3(ipad || M)) is used as a fixed-length pseudo-random key (PRK).

[0059] Specifications for parameters during key derivation: PRK length: 32 bytes (SM3 output length); Maximum length of info: Unlimited; Output key material length: maximum 255x32=8160 bytes.

[0060] In one possible implementation, a format conversion step is included before the key encapsulation party performs the encapsulation operation or the key decapsulation party performs the decapsulation operation: Convert the Jacobian coordinate representation of the SM2 public key used for internal calculations into a 65-byte uncompressed byte sequence conforming to the SEC 1 standard; or, The received 65-byte uncompressed SM2 public key conforming to the SEC 1 standard is parsed, verified, and converted into the Jacobian coordinate representation used for internal calculations.

[0061] In one possible implementation, the steps for verifying the SM2 public key include: The byte sequence length of the SM2 public key is verified to be 65 bytes, with the first byte being a predetermined value representing the uncompressed point; And / or, verify that the point corresponding to the SM2 public key is located on the SM2 elliptic curve.

[0062] In the process of integrating the SM2 algorithm with modern encryption protocols such as HPKE, a key technical obstacle lies in the difference between the internal data structure of the underlying C language library of the Chinese cryptographic algorithm and the standardized byte array format required by the upper-layer protocol stack, which constitutes a serious interoperability bottleneck.

[0063] To address this issue, in one possible implementation, this application introduces a zero-copy format conversion mechanism and specifically applies it to the conversion of SM2 key formats.

[0064] This mechanism mainly includes the following two core conversion processes, aiming to achieve high-performance, bidirectional format adaptation without additional memory copying: 1. SM2 private key format conversion The internal representation of the SM2 private key in the underlying library, namely a large integer of type sm2_z256_t (usually an array of four 64-bit unsigned integers), is converted into the 32-byte big-endian standard byte array format that is transmitted and stored in the protocol.

[0065] 2. SM2 public key format conversion like Figure 4 The diagram shows the SM2 public key format conversion flowchart. This process enables bidirectional conversion between the efficient internal computation representation of the Chinese cryptographic algorithm and the external standardized protocol format, ensuring algorithm performance and protocol interoperability. The process primarily involves the conversion between two data representation formats: the Jacobian projective coordinates used for internal computation (typically represented as a triple (X, Y, Z)), and the uncompressed byte sequence format conforming to the international standard SEC 1 (65 bytes, starting with 0x04 followed by 32 bytes of x-coordinate and 32 bytes of y-coordinate).

[0066] (1) Convert Jacobian coordinates to SEC 1 format (serialization) This conversion encodes the efficient Jacobian coordinate representation used in internal calculations into a standardized byte sequence for easier network transmission or storage. The specific steps are as follows: Calculate the modular inverse: First, calculate the modular inverse of the Z component in the Jacobian projective coordinates SM2_Z256_POINT (X, Y, Z): z_inv = Z^(-1) mod p, where p is the domain prime of the SM2 elliptic curve, and mod p is the modulo operation, i.e., taking the remainder with respect to p, ensuring that the result is in the range [0, p-1]. Transform to affine coordinates: Calculate the affine coordinates (x, y) using z_inv: x = X × (z_inv)^2 mod p; y = Y × (z_inv)^3 mod p; (z_inv)^2 mod p represents the square of the inverse of the Z-component's modulus z_inv modulo p, and (z_inv)^3 mod p represents the cube of the inverse of the Z-component's modulus z_inv modulo p.

[0067] Encoding output: The affine coordinates are encoded into a 65-byte SEC 1 uncompressed format: the first byte is set to 0x04 as the uncompressed point identifier, followed by the concatenation of the 32-byte big-endian representation of the x-coordinate and the 32-byte big-endian representation of the y-coordinate.

[0068] (2) Convert SEC 1 format to Jacobian coordinates (deserialization) This transformation parses the received standardized public key byte stream and converts it into the coordinate form required for internal computation, while performing necessary verification to ensure the validity and security of the input. The specific steps are as follows: Format validation: Verify that the length of the input byte sequence is 65 bytes and that the first byte is 0x04, confirming that it is a valid uncompressed point format; Coordinate parsing: Parse the affine coordinates from the byte sequence: x = bytes[1:33], y = bytes[33:65] (both are big-endian encoded); Curve point verification (optional): Substitute the parsed (x, y) into the SM2 elliptic curve equation to verify that the point is indeed located on the curve, in order to defend against invalid curve attacks; Constructing Jacobian coordinates: Directly construct the Jacobian coordinate representation: (X = x, Y = y, Z = 1); Through the bidirectional conversion process described above, this method maintains the high computational efficiency of the SM2 algorithm (by using Jacobian coordinates to avoid modular inverse operations) while ensuring that the public key data is fully compatible with the SEC 1 format required by standard protocols such as HPKE and MLS, providing a key format adaptation layer for the integration of the SM2 algorithm into standard cryptographic protocol stacks.

[0069] Furthermore, through the aforementioned zero-copy format conversion mechanism, this scheme efficiently bridges the underlying national cryptographic algorithm implementation with the upper-layer standard protocol stack. While maintaining the optimal computational performance of the national cryptographic algorithm, it ensures that its output is fully compatible with the format requirements of international standard protocols such as HPKE, thereby clearing away the core obstacles for the application of the SM2 algorithm in a wide range of standard encryption ecosystems.

[0070] In one possible implementation, Figure 5 This embodiment illustrates the complete HPKE encrypted communication context workflow built upon the SM2 Key Encapsulation Mechanism (KEM) and a suite of national cryptographic algorithms, as provided in this application. The workflow achieves end-to-end secure operation from non-interactive key negotiation to symmetric encrypted communication, specifically divided into two main stages: context initialization and data encryption / decryption.

[0071] 1. Context initialization phase (Setup) This stage aims to establish a shared cryptographic context between the communicating parties, including key derivation and parameter synchronization.

[0072] The sender first calls the `SM2_KEM.Encap` function to perform key encapsulation using the receiver's public key (`receiver_pk`), outputting the encapsulation result `enc` (i.e., the temporary public key, 65 bytes) and the shared secret. Then, using the `shared_secret` as the input key material (`IKM`), it calls `SM3_KDF` for key derivation. Specifically, it first extracts the pseudo-random key (`PRK`) through the `Extract` step, and then derives the symmetric key (e.g., a 16-byte encryption key `key`) and initialization vector (e.g., a 12-byte base random number `nonce`) required for the session through the `Expand` step, combining specific application information. Finally, it initializes the sender context `HpkeContextS` using these parameters and sets the initial sequence number `sequence` to 0.

[0073] The receiver, upon receiving the encapsulation result `enc`, calls the `SM2_KEM.Decap` function to decapsulate `enc` using its own private key (`local_sk`), restoring the same shared secret. The receiver then uses the exact same `SM3_KDF` derivation process and input parameters as the sender to derive the identical key and base nonce, and initializes its own context `HpkeContextR`, setting `sequence=0`. Thus, a shared encrypted state is established between the two parties without any interactive negotiation.

[0074] 2. Data encryption / decryption phase (Seal / Open) This stage utilizes the established context to authenticate, encrypt, and decrypt application data.

[0075] Encryption (Seal): Before encrypting each message, the sender dynamically calculates the actual nonce used for this encryption based on the current sequence number, i.e., actual_nonce = base_nonce XOR sequence. This design ensures the uniqueness of the nonce for each encryption operation. Subsequently, the SM4-GCM authentication encryption algorithm is called, using the negotiated key, the calculated actual_nonce, and additional authentication data (aad) to encrypt the plaintext, generating ciphertext and an authentication tag. After encryption, the sequence number in the sender's context is incremented.

[0076] Decryption (Open): After receiving the ciphertext, the receiver uses the same locally maintained sequence number to calculate the nonce required for decryption using the exact same formula (actual_nonce = base_nonce XOR sequence). Then, it calls the SM4-GCM decryption algorithm, using the same key, the calculated actual_nonce, and aad to decrypt and authenticate the ciphertext. Upon successful authentication, the plaintext is output, and the local sequence number is incremented to maintain synchronization with the sender's state.

[0077] In summary, this workflow achieves non-interactive key negotiation through SM2_KEM, deterministic key derivation through SM3_KDF, and efficient and secure authentication and encryption communication through SM4-GCM combined with a sequence number mechanism, forming a complete HPKE protocol instance based on Chinese national cryptographic algorithms.

[0078] In one possible implementation, secondly, this application provides a key encapsulation system for the HPKE protocol, comprising: The key negotiation module is used to implement the encapsulation and / or decapsulation operations in any of the key encapsulation methods mentioned above to generate a shared key; The key derivation module is used to implement key extraction based on the SM3 hash message authentication code function, so as to derive the encryption key and initialization vector from the shared key; The format conversion module uses a zero-copy format conversion mechanism to directly convert the internal data structure of the underlying national cryptographic algorithm library into the standard data format required by the HPKE protocol. Specifically, the format conversion includes: converting the Jacobian coordinate representation of the SM2 public key used for internal calculations into a 65-byte uncompressed byte sequence conforming to the SEC 1 standard; or, The received 65-byte uncompressed SM2 public key conforming to the SEC 1 standard is parsed, verified, and converted into the Jacobian coordinate representation used for internal calculations.

[0079] The cryptographic suite management module is used to store and manage the identifiers of the components of the national cryptographic algorithm.

[0080] Specifically, the cryptographic suite management module is used to define identifiers for identifying components of the national cryptographic algorithm, and the identifiers are within a preset private value range; The identifier includes at least a first identifier for identifying the SM2-based key encapsulation mechanism, a second identifier for identifying the SM3-based key derivation function, and a third identifier for identifying the SM4-GCM authentication encryption algorithm.

[0081] Preferably, the private value range is 0xFF00 to 0xFFFF; the first identifier is 0xFF03, the second identifier is 0xFF02, and the third identifier is 0xFF01.

[0082] The system integrates four core modules: key negotiation, key derivation, format conversion, and suite management. In addition, the "zero-copy format conversion mechanism" significantly reduces the memory copying overhead in data processing and improves the system's performance in high-concurrency and high-throughput scenarios.

[0083] In one possible implementation, the zero-copy format conversion mechanism includes: Allocate a fixed-size buffer in the stack memory; The pointer to the buffer is passed to the underlying conversion function through the external function interface, and the underlying conversion function writes the conversion result. Automatically clear the buffer that stores sensitive key data.

[0084] The key encapsulation system in this embodiment is equipped with a zero-copy format conversion mechanism. Through a combination of "stack allocation + direct writing + automatic zeroing," it achieves the triple benefits of zero heap overhead, zero memory copying, and automatic memory security management. Real-world testing shows that stack allocation is more than 25 times faster than heap allocation, while completely eliminating the risks of memory leaks and key residues caused by manual memory management errors.

[0085] Preferably, before the key encapsulation party performs the encapsulation operation or the key decapsulation party performs the decapsulation operation, a format conversion step is also included: Preferably, the steps for verifying the SM2 public key include: The byte sequence length of the SM2 public key is verified to be 65 bytes, with the first byte being a predetermined value representing the uncompressed point; And / or, verify that the point corresponding to the SM2 public key is located on the SM2 elliptic curve.

[0086] The key encapsulation system provided in this embodiment innovatively combines SM2-ECDH (SM2 Elliptic Curve Diffie-Hellman Key Exchange Algorithm) and SM3-HMAC (SM3 Hash Message Authentication Code Function), transforming the key exchange protocol in the SM2 standard, which requires two-way interaction, into a one-way non-interactive KEM primitive conforming to the HPKE standard. This fundamental transformation enables the Chinese national cryptographic algorithm to be seamlessly integrated into modern protocols such as HPKE and MLS for the first time using a standard KEM interface, filling the technical gap of the Chinese national cryptographic algorithm in non-interactive key distribution scenarios and solving the long-standing problem of protocol semantic adaptation.

[0087] The key encapsulation system provided in this embodiment defines a specific concatenation method for a 194-byte KDF input. This construction concatenates the temporary public key, the recipient's public key, and the shared key in a fixed order. Its technical value lies in: ① Security level: By binding the public keys of both parties, an identity binding attribute is provided for the shared key, effectively preventing identity confusion and unknown key sharing attacks; including the temporary public key ensures that each encapsulation is unique. ② Engineering level: This construction strictly specifies that the public key adopts the SEC 1 standard 65-byte uncompressed format, enabling different implementations to generate completely identical input data, thereby deriving a consistent shared key and ensuring determinism and interoperability across platforms and implementations.

[0088] The key encapsulation system provided in this embodiment not only solves the algorithm adaptation problem but also offers a complete integration solution. At the implementation layer, a format conversion and verification mechanism that balances efficiency and security is designed to ensure efficient internal computation and secure conversion to external standard formats. At the protocol layer, an innovative national cryptographic algorithm identifier system within a private numerical range (0xFF00-0xFFFF) is defined to avoid conflicts with IANA-registered standard suites, laying a standardized foundation for HPKE / MLS protocol identification and invocation of national cryptographic suites. This forms an end-to-end solution from underlying algorithm construction and middleware implementation to upper-layer protocol identification.

[0089] In one possible implementation, an HPKE encrypted communication method based on Chinese national cryptographic algorithms is provided, including a key negotiation phase and a data transmission phase: During the key negotiation phase, the sender and receiver negotiate a shared key using any of the above-mentioned key encapsulation methods based on the SM2 algorithm. Based on the shared key, the encryption key and initialization vector are derived using the SM3 hash message authentication code function; During the data transmission phase, the sender uses the encryption key, initialization vector, and SM4-GCM authentication encryption algorithm to encrypt the plaintext data to obtain ciphertext and then sends it. The receiver uses the encryption key, initialization vector, and SM4-GCM authentication encryption algorithm to decrypt the received ciphertext to obtain plaintext data.

[0090] In one possible implementation, during the key negotiation phase, the sender performs an encapsulation operation, generates and sends the encapsulated output, which includes a temporary public key. The receiver receives the encapsulated output and performs a decapsulation operation to obtain the shared key; The sender and receiver use the same context information and derive the same encryption key and initialization vector based on the shared key.

[0091] In one possible implementation, the HPKE encrypted communication method further includes: providing a unified cryptographic service interface for the national cryptographic algorithm through a cryptographic suite management module, which is used to manage the identifiers of the national cryptographic algorithm components.

[0092] In one possible implementation, the HPKE encrypted communication method provides a unified configuration and service interface for the Chinese national cryptographic algorithm components through a cryptographic suite management module. This module is the core adaptation layer between the Chinese national cryptographic algorithm and the standard HPKE protocol stack, and its primary function is to manage and map the standardized identifiers of the Chinese national cryptographic algorithm components.

[0093] According to RFC 9180, the HPKE protocol is built in a modular fashion, clearly distinguishing between three components: Key Encapsulation Mechanism (KEM), Key Derivation Function (KDF), and Authentication Encryption Algorithm (AEAD). Therefore, the cipher suite management module implements the following adaptation functions for the Chinese national cryptographic algorithm: 1. Identifier Registration and Resolution: The cryptographic suite management module maintains an internal registry that binds the private identifiers of Chinese cryptographic algorithm components (e.g., 0xFF01 for SM4-GCM, 0xFF02 for SM3-HKDF, and 0xFF03 for SM2-KEM) to the algorithm instances required for HPKE standard operation. When the protocol stack specifies the use of a Chinese cryptographic algorithm suite, the module can correctly parse and return the corresponding algorithm implementation.

[0094] 2. Algorithm Instance Lifecycle Management: The module provides a unified factory method or initialization interface for dynamically creating and configuring running instances of national cryptographic algorithm components. For example, it can obtain a configured SM2-KEM executor, an SM3-HKDF derivative, or an SM4-GCM encryptor / decryptor based on an identifier.

[0095] 3. Unified Cryptographic Service Interface: This module provides a streamlined and stable service interface (e.g., GmCipherSuite). This interface encapsulates the core primitives required for HPKE operations, mainly including: KEM interface: Provides Encap and Decap methods, which internally call the SM2 key encapsulation mechanism of this invention; KDF interface: Provides Extract and Expand methods, which are internally implemented by SM3-HMAC and SM3-KDF; AEAD interface: Provides Seal (encryption) and Open (decryption) methods, and is internally implemented using the SM4-GCM algorithm.

[0096] Through this cryptographic suite management module, the national cryptographic algorithm components of this application exist as a plug-and-play "suite" conforming to the HPKE framework specification. The upper-layer HPKE protocol stack does not need to be aware of the specific implementation details of the underlying national cryptographic algorithm. It only needs to call the standard interface and the identifier issued by the module to seamlessly access the complete cryptographic services provided by SM2, SM3, and SM4. Thus, while ensuring the compliance of national cryptographic algorithms, it achieves full compatibility with the internationally used encryption protocol ecosystem.

[0097] This embodiment constructs a complete, end-to-end national cryptographic secure communication process. The method covers the entire chain from key negotiation (SM2-KEM+SM3-KDF) to data transmission (SM4-GCM), demonstrating that this patented technology can effectively support modern secure group communication protocols and has significant practical application value.

[0098] The design utilizes a "cryptographic suite adaptation module" to provide a unified interface for Chinese cryptographic algorithms. This reduces the complexity of integrating Chinese cryptographic algorithms into upper-layer applications (such as the MLS protocol stack). Applications do not need to concern themselves with the specific implementation details of the underlying Chinese cryptographic algorithms; they only need to call them through the standard interface, which greatly improves the ease of use and scalability of Chinese cryptographic algorithms.

[0099] The HPKE encrypted communication method based on the national cryptographic algorithm provided in this embodiment can maintain interoperability with existing HPKE implementations, and therefore can be seamlessly integrated into protocols such as MLS and TLS.

[0100] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware, or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0101] The foregoing has described specific embodiments of the present application. In some cases, the described actions or steps may be performed in a different order than those shown in the embodiments and the desired results may still be achieved. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired results. In some implementations, multitasking and parallel processing are also possible or may be advantageous.

[0102] In the description of the embodiments of this application, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the embodiments of this application. In the embodiments of this application, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in a suitable manner in any one or more embodiments or examples. Furthermore, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in the embodiments of this application, as well as the features of different embodiments or examples.

[0103] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing custom logic functions or processes, and the scope of preferred embodiments of the invention includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of the invention pertain.

[0104] The above embodiments are merely preferred embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A key encapsulation method applied to the HPKE protocol, characterized in that, The key encapsulation party performs an encapsulation operation, which includes: S11. Generate an SM2 temporary key pair, wherein the SM2 temporary key pair includes a temporary private key and a temporary public key; S12. Using the temporary private key and the recipient's SM2 public key, execute the SM2 elliptic curve Diffie-Hellman key exchange algorithm to calculate the first shared point; S13. The temporary public key, the receiver's SM2 public key, and the first sharing point are concatenated in a first predetermined order to generate input data; S14. Based on the input data, extract the key using the SM3 hash message authentication code function to generate a shared key; The output of the encapsulation operation includes the temporary public key and the shared key.

2. The key encapsulation method according to claim 1, characterized in that, The input data is constructed by sequentially concatenating the temporary public key, the receiver's SM2 public key, and the first sharing point. The temporary public key and the recipient's SM2 public key are in 65-byte uncompressed format conforming to the SEC 1 standard, the first shared point is 64 bytes, and the total length of the input data is 194 bytes.

3. The key encapsulation method according to claim 1 or 2, characterized in that, The key encapsulation method further includes a key decapsulation party performing a decapsulation operation, the decapsulation operation including: S21. Receive the temporary public key from the key encapsulation party; S22. Using the local SM2 private key and the temporary public key, execute the SM2 elliptic curve Diffie-Hellman key exchange algorithm to calculate the second shared point; S23. Based on the temporary public key, the local SM2 public key, and the second sharing point, concatenate them in the first predetermined order to construct identical input data; S24. Based on the input data, use the SM3 hash message authentication code function to extract the key and generate the same shared key.

4. The key encapsulation method according to claim 3, characterized in that, Before the key encapsulation party performs the encapsulation operation or the key decapsulation party performs the decapsulation operation, a format conversion step is also included: Convert the Jacobian coordinate representation of the SM2 public key used for internal calculations into a 65-byte uncompressed byte sequence conforming to the SEC 1 standard; or, The received 65-byte uncompressed SM2 public key conforming to the SEC 1 standard is parsed, verified, and converted into the Jacobian coordinate representation used for internal calculations.

5. The key encapsulation method according to claim 4, characterized in that, The steps for verifying an SM2 public key include: Verify that the byte sequence length of the SM2 public key is 65 bytes and that the first byte is a predetermined value representing an uncompressed point; And / or, verify that the point corresponding to the SM2 public key is located on the SM2 elliptic curve.

6. The key encapsulation method according to claim 1, characterized in that, The key encapsulation method further includes: Define an identifier for identifying components of the national cryptographic algorithm, wherein the identifier is within a preset private numerical range; The identifier includes at least a first identifier for identifying the SM2-based key encapsulation mechanism, a second identifier for identifying the SM3-based key derivation function, and a third identifier for identifying the SM4-GCM authentication encryption algorithm.

7. The key encapsulation method according to claim 6, characterized in that, The private value range is 0xFF00 to 0xFFFF; the first identifier is 0xFF03, the second identifier is 0xFF02, and the third identifier is 0xFF01.

8. A key encapsulation system for the HPKE protocol, characterized in that, include: A key negotiation module is used to implement the encapsulation and / or decapsulation operations in the key encapsulation method as described in any one of claims 1 to 7, so as to generate a shared key; The key derivation module is used to implement key extraction based on the SM3 hash message authentication code function, so as to derive the encryption key and initial vector from the shared key; The format conversion module adopts a zero-copy format conversion mechanism to directly convert the internal data structure of the underlying national cryptographic algorithm library into the standard data format required by the HPKE protocol; The cryptographic suite management module is used to store and manage the identifiers of the components of the national cryptographic algorithm.

9. An HPKE encrypted communication method based on Chinese national cryptographic algorithms, characterized in that, Includes the key negotiation phase and the data transmission phase: During the key negotiation phase, the sender and receiver negotiate a shared key using the key encapsulation method based on the SM2 algorithm as described in any one of claims 1 to 7. Based on the shared key, the encryption key and initialization vector are derived using the SM3 hash message authentication code function; During the data transmission phase, the sender uses the encryption key, the initialization vector, and the SM4-GCM authentication encryption algorithm to encrypt the plaintext data to obtain ciphertext and then sends it. The receiver uses the encryption key, the initialization vector, and the SM4-GCM authentication encryption algorithm to decrypt the received ciphertext to obtain plaintext data.

10. The HPKE encrypted communication method according to claim 9, characterized in that, During the key negotiation phase, the sender performs the encapsulation operation, generates and sends the encapsulation output, which includes a temporary public key. The receiver receives the encapsulated output and performs a decapsulation operation to obtain the shared key; The sender and the receiver use the same context information to derive the same encryption key and initialization vector based on the shared key.

11. The HPKE encrypted communication method according to claim 10, characterized in that, The HPKE encrypted communication method further includes: providing a unified cryptographic service interface for the national cryptographic algorithm through a cryptographic suite management module, wherein the cryptographic suite management module is used to manage the identifiers of the national cryptographic algorithm components.

Images