Two-party collaborative decryption method, device and storage medium

Abstract

This application provides a two-party collaborative decryption method, device, and storage medium. The method includes: a client generating a first decryption parameter using a first private key component generated and stored by a key management center; the key generation center generating a second decryption parameter using a second private key component it holds and the first decryption parameter sent by the client; and the client reconstructing a shared key point based on the second decryption parameter to recover the plaintext message corresponding to the ciphertext to be decrypted. The plaintext message can be recovered through only one round of decryption parameter exchange during the decryption process, without directly exposing or combining the private key components, thus avoiding the risk of interception or tampering during private key component interaction. Furthermore, the client submits the first decryption parameter to the key generation center each time it decrypts. Therefore, in legitimate authorization scenarios, the decryption process can be reconstructed solely based on the historical first decryption parameter and the second decryption parameter held by the key generation center, meeting legitimate regulatory requirements.

Description

Technical Field

[0001] This application relates to the field of data security technology, and in particular to a two-party collaborative decryption method, device and storage medium. Background Technology

[0002] The SM2 elliptic curve public-key cryptography algorithm is a general-purpose commercial cryptographic standard widely used in information security scenarios such as data encryption. To enhance private key security, the decryption process can be completed collaboratively by two parties. Specifically, by splitting the user's private key into two components, which are stored separately by the client and server, the decryption operation requires cooperation from both parties. This effectively prevents any single party from obtaining the complete private key independently, thus improving the security of key storage and usage.

[0003] However, with increasingly stringent data security governance requirements, some application scenarios (such as judicial evidence collection, corporate data compliance audits, and disaster recovery) have further raised the need for legally authorized access to encrypted data, under the premise of ensuring user privacy and data confidentiality. Specifically, this requires supporting trusted third-party participation in key reconstruction to achieve data recovery, provided specific policies or regulatory conditions are met. However, traditional two-party collaborative decryption schemes can only achieve private key fragmentation protection, failing to meet the regulatory requirements for keys in encrypted scenarios and not supporting key escrow and data recovery under legal authorization. Therefore, a new two-party collaborative decryption scheme compatible with the SM2 standard is urgently needed to ensure private key security and data confidentiality while meeting emerging security needs such as regulatory compliance and emergency data recovery. Summary of the Invention

[0004] This application provides a two-party collaborative decryption method, device, and storage medium to ensure the security of the private key and the confidentiality of the data while meeting the regulatory requirements for the encryption key.

[0005] In a first aspect, embodiments of this application provide a two-party collaborative decryption method applied to a client, the method comprising: In response to a user's decryption request for the ciphertext to be decrypted, verify whether the temporary public key in the ciphertext to be decrypted is a non-infinity point on an elliptic curve. If the verification is successful, the temporary public key is bound to the user's first private key component to generate the first decryption parameter; the first private key component is generated and distributed to the client by the key management center during the user registration phase. The first decryption parameter is sent to the key generation center so that the key generation center can verify the validity of the first decryption parameter and use the user's second private key component held by it to perform collaborative key processing on the first decryption parameter to obtain the second decryption parameter; Determine the shared key point based on the second decryption parameter and the temporary public key; Based on the shared key point, the ciphertext in the ciphertext to be decrypted is decrypted to obtain the candidate plaintext message; A message authentication code is generated based on the candidate plaintext message and the shared key point. If the message authentication code matches the hash value in the ciphertext to be decrypted, then the candidate plaintext message is determined as the plaintext message corresponding to the ciphertext to be decrypted.

[0006] Secondly, embodiments of this application provide a two-party collaborative decryption device applied to a client, the device comprising: The response module is used to respond to a user's decryption request for the ciphertext to be decrypted and to verify whether the temporary public key in the ciphertext to be decrypted is a non-infinity point on an elliptic curve. The processing module is used to perform private key binding processing on the temporary public key based on the user's first private key component if the verification is successful, and generate a first decryption parameter; the first private key component is generated and distributed to the client by the key management center during the user registration stage; The sending module is used to send the first decryption parameter to the key generation center so that the key generation center can verify the validity of the first decryption parameter and use the user's second private key component held by it to perform collaborative key processing on the first decryption parameter to obtain the second decryption parameter; The determining module is used to determine a shared key point based on the second decryption parameter and the temporary public key; The decryption module is used to decrypt the ciphertext of the message in the ciphertext to be decrypted based on the shared key point to obtain the candidate plaintext message; The generation module is used to generate a message authentication code based on the candidate plaintext message and the shared key point. If the message authentication code matches the hash value in the ciphertext to be decrypted, the candidate plaintext message is determined as the plaintext message corresponding to the ciphertext to be decrypted.

[0007] Thirdly, embodiments of this application provide an electronic device applied to a client, comprising: a memory, a processor, and a communication interface; wherein, the memory stores executable code, and when the executable code is executed by the processor, the processor can at least implement the two-party collaborative decryption method as described in the first aspect.

[0008] Fourthly, embodiments of this application provide a non-transitory machine-readable storage medium storing executable code, which, when executed by a processor of an electronic device, enables the processor to at least implement the two-party collaborative decryption method as described in the first aspect.

[0009] Fifthly, embodiments of this application provide a computer program product, including: a computer program or instructions, which, when executed by a processor of an electronic device, enable the processor to at least implement the two-party collaborative decryption method as described in the first aspect.

[0010] Sixthly, embodiments of this application provide a two-party collaborative decryption method, applied to a key generation center for collaborative decryption with a client, the method comprising: The client receives a first decryption parameter, which is obtained by binding the temporary public key to the first private key component held by the client after the temporary public key in the ciphertext to be decrypted has been verified. The validity of the first decryption parameter is verified by elliptic curve points. If the verification is successful, the first decryption parameter is processed by a collaborative key using the user's second private key component to obtain the second decryption parameter. The second decryption parameter is sent to the client so that the client determines a shared key point based on the second decryption parameter and the temporary public key, and decrypts the ciphertext in the ciphertext to be decrypted based on the shared key point to obtain a candidate plaintext message. If the message authentication code generated based on the candidate plaintext message and the shared key point matches the hash value in the ciphertext to be decrypted, then the candidate plaintext message is determined as the plaintext message corresponding to the ciphertext to be decrypted.

[0011] Seventhly, embodiments of this application provide a two-party collaborative decryption device, applied to a key generation center for collaborative decryption with a client, the device comprising: The receiving module is used to receive the first decryption parameter sent by the client. The first decryption parameter is obtained by binding the temporary public key to the temporary public key based on the first private key component held by the client, after the temporary public key in the ciphertext to be decrypted has been verified. The processing module is used to perform elliptic curve point validity verification on the first decryption parameter. If the verification is successful, the module uses the user's second private key component to perform collaborative key processing on the first decryption parameter to obtain the second decryption parameter. The sending module is configured to send the second decryption parameter to the client, so that the client determines a shared key point based on the second decryption parameter and the temporary public key, and decrypts the message ciphertext in the ciphertext to be decrypted based on the shared key point to obtain a candidate plaintext message. If the message authentication code generated based on the candidate plaintext message and the shared key point matches the hash value in the ciphertext to be decrypted, then the candidate plaintext message is determined as the plaintext message corresponding to the ciphertext to be decrypted.

[0012] Eighthly, embodiments of this application provide an electronic device applied to a verification end, comprising: a memory, a processor, and a communication interface; wherein, the memory stores executable code, and when the executable code is executed by the processor, the processor can at least implement the two-party collaborative decryption method as described in the sixth aspect.

[0013] In a ninth aspect, embodiments of this application provide a non-transitory machine-readable storage medium storing executable code, which, when executed by a processor of an electronic device, enables the processor to at least implement the two-party collaborative decryption method as described in the sixth aspect.

[0014] In a tenth aspect, embodiments of this application provide a computer program product, including: a computer program or instructions that, when executed by a processor of an electronic device, enable the processor to at least implement the two-party collaborative decryption method as described in the sixth aspect.

[0015] The two-party collaborative decryption scheme provided in this application embodiment can be applied to a client, which uses its first private key component generated by the key management center and the second private key component persisted by the key generation center to collaboratively decrypt the ciphertext to be encrypted corresponding to the encryption key disclosed by the client, thereby ensuring the security of the private key and the confidentiality of the data while meeting the regulatory requirements of the encryption key.

[0016] In practice, upon receiving a decryption request from a user for ciphertext to be decrypted, the client responds by verifying whether the temporary public key in the ciphertext is a non-infinity point on an elliptic curve. The ciphertext to be decrypted includes the temporary public key, the message ciphertext, and a hash value. If the temporary public key is a non-infinity point on an elliptic curve, the client obtains the user's first private key component, which is generated and distributed to the client by the key management center during the user's key registration phase. Next, based on the user's first private key component, the client performs private key binding processing on the temporary public key to generate a first decryption parameter. This first decryption parameter is sent to the key generation center for verification. If verification is successful, the client uses the second private key component held by the key generation center to perform collaborative key processing on the first decryption parameter to obtain a second decryption parameter, which is then sent to the client. Upon receiving the second decryption parameter, the client determines a shared key point based on the second decryption parameter and the temporary public key. Then, based on this shared key point, the client decrypts the message ciphertext in the ciphertext to be decrypted to obtain the candidate plaintext message. A message authentication code is generated based on the candidate plaintext message and the shared key point. When the message authentication code matches the hash value in the ciphertext to be decrypted, the candidate plaintext message is determined as the plaintext message corresponding to the ciphertext to be decrypted.

[0017] In the above scheme, when the client and the key generation center perform collaborative decryption, the client uses its locally stored first private key component generated by the key management center to bind the temporary public key in the ciphertext to be decrypted, generating a first decryption parameter and sending it to the key generation center. The key generation center then uses its second private key component to process the first decryption parameter, obtaining a second decryption parameter. That is, in this collaborative decryption process, the client and the key generation center only exchange decryption parameters, without directly exposing or combining private key components. This avoids the risk of interception or tampering of private key components during collaborative decryption. The client can directly reconstruct the shared key point based on the second decryption parameter and the temporary public key to recover the plaintext message corresponding to the ciphertext to be decrypted. Furthermore, since the user's complete private key is generated and stored by both the key management center and the key generation center, it can be obtained from these centers when regulatory oversight is required. Each time the client decrypts, it submits the first decryption parameter to the key generation center, which records these values. Thus, in legitimate authorization scenarios, the decryption process can be reconstructed using only the historical first decryption parameter and the second decryption parameter held by the key generation center, without requiring further user intervention. This allows for legitimate regulatory oversight and emergency recovery of encrypted data without compromising original security. Additionally, during collaborative decryption, the collaborative decryption process continues only after both the client and key generation center verify the temporary public key and the first decryption parameter. This dual validity verification by both parties prevents the decryption of tampered ciphertext, further ensuring data confidentiality. Attached Figure Description

[0018] 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 some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a schematic diagram of a two-party collaborative decryption system provided in an embodiment of this application; Figure 2 A flowchart of a two-party collaborative decryption method provided in this application embodiment; Figure 3 A flowchart illustrating another two-party collaborative decryption method provided in this application embodiment; Figure 4 This is a schematic diagram of the structure of a two-party collaborative decryption device provided in an embodiment of this application; Figure 5 To and Figure 4A schematic diagram of the electronic device corresponding to the two-party collaborative decryption device provided in the embodiment shown. Figure 6 A schematic diagram of another two-party collaborative decryption device provided in this application embodiment; Figure 7 To and Figure 6 The illustrated embodiment provides a schematic diagram of the electronic device corresponding to the two-party collaborative decryption device. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0021] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to limit the application. The singular forms “a,” “the,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms, unless the context clearly indicates otherwise. “Multiple” generally includes at least two, but does not exclude the inclusion of at least one. It should be understood that the term “and / or” as used herein is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. Additionally, the character “ / ” in this document generally indicates that the preceding and following related objects are in an “or” relationship. Depending on the context, the words “if” or “when” as used herein can be interpreted as “when…” or “when…”.

[0022] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a product or system comprising a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a product or system. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the product or system that includes said element.

[0023] Furthermore, the timing of the steps in the following method embodiments is merely an example and not a strict limitation.

[0024] To address the security issues associated with single-key management, a user's complete private key can be fragmented and stored, with each participating party holding a fragment collaboratively completing the decryption process. Specifically, this involves splitting the user's private key into two components, one stored by the client and one by the server. During decryption, both parties collaborate using zero-knowledge proofs or multiple rounds of key negotiation to complete the decryption process. This effectively prevents any single party from obtaining the complete private key independently, thus enhancing the security of key storage and usage.

[0025] However, most of these schemes only implement key fragment storage, which carries the risk of interception and tampering during private key component exchanges. Furthermore, they do not meet the standard specifications of the SM2 algorithm, resulting in unreliable decryption accuracy. In addition, traditional two-party collaborative decryption schemes often employ complex key negotiation mechanisms, which are computationally inefficient and difficult to adapt to high-concurrency data decryption scenarios.

[0026] Furthermore, with increasingly stringent data security governance requirements, some application scenarios (such as judicial evidence collection, corporate data compliance audits, and disaster recovery) have raised the need for legally authorized access to encrypted data, under the premise of ensuring user privacy and data confidentiality. This means supporting trusted third-party participation in key reconstruction to achieve data recovery, provided specific policies or regulatory conditions are met. However, traditional two-party collaborative decryption schemes can only achieve private key fragmentation protection, failing to meet the regulatory requirements for keys in encrypted scenarios and not supporting key escrow and data recovery under legal authorization.

[0027] To address the aforementioned technical issues, this application proposes a novel two-party collaborative decryption scheme. In this scheme, the client uses a first private key component generated and stored by a key management center to generate a first decryption parameter. The key generation center uses its second private key component and the first decryption parameter sent by the client to generate a second decryption parameter. The client then reconstructs the shared key point based on the second decryption parameter to recover the plaintext message corresponding to the ciphertext to be decrypted. This collaborative decryption process recovers the plaintext message through only one round of decryption parameter exchange, without directly exposing or combining private key components, thus avoiding the risk of interception or tampering during private key component interaction. Furthermore, since the user's complete private key is generated and stored by both the key management center and the key generation center, it can be obtained from these centers when regulatory oversight is required. Each time the client decrypts, it submits a first decryption parameter to the key generation center, which can selectively record these values. Thus, in legitimate authorization scenarios, the user does not need to participate again; the decryption process can be reconstructed using only the historical first decryption parameter and the second decryption parameter held by the key generation center, allowing the plaintext message to be recovered. This satisfies the needs for legitimate oversight and emergency recovery of encrypted data without compromising original security. Additionally, during collaborative decryption, the collaborative decryption process continues only after both the client and key generation center verify the temporary public key and the first decryption parameter. This dual validity verification by both parties prevents the decryption of tampered ciphertext, further ensuring data confidentiality.

[0028] The following embodiments illustrate the collaborative decryption scheme between the two parties.

[0029] Figure 1 This is a schematic diagram of a two-party collaborative decryption system provided in an embodiment of this application, as shown below. Figure 1 As shown, the system may include a key management center, a client, and a key generation center that collaborates with the client for decryption.

[0030] The client can be any device that needs to initiate key generation requests to the key management center and key generation center to obtain the user's complete public key, and initiate collaborative decryption requests to the key generation center to obtain the plaintext message corresponding to the ciphertext to be decrypted. Specifically, the client can be a mobile phone, PC, tablet computer, configuration application, etc. It can also be any device capable of providing computing services, such as a cluster server, regular server, cloud server, cloud host, virtual data center, etc.

[0031] The key management center is primarily used to independently generate and store the first private key component of a user's complete private key. The key generation center is primarily used to independently generate and store the second private key component of a user's complete private key during the user registration key phase, and to perform collaborative decryption processing with the client during the decryption collaboration phase. That is, both the key generation center and the client are equipped with the two-party collaborative decryption device described in this application to perform the corresponding two-party collaborative decryption operations.

[0032] Furthermore, to avoid private key security vulnerabilities, during the collaborative generation of user keys, the key management center distributes its generated first private key component to the corresponding client, while the key generation center only sends the public key component corresponding to the generated second private key component to the client. The client generates the key by combining the private key component provided by the key management center and the public key component provided by the key generation center. In this way, the key management center, the key generation center, and the client cannot directly obtain the first and second private key components corresponding to the user's complete private key. Moreover, the user's complete private key always exists in fragmented form and is not explicitly assembled to prevent the user's complete private key from appearing in plaintext form in any single execution entity.

[0033] The key registration phase will be explained in detail below.

[0034] In practical applications, when a user needs to generate a key, they can send a private key collaborative generation request to the key generation center and the key management center through a client. Specifically, when the client receives the private key collaborative generation request triggered by the user, it responds to the request and forwards it to the key generation center and the key management center.

[0035] Upon receiving the private key collaborative generation request, the key management center generates a first random number and uses this first random number as the user's first private key component. Based on this first private key component, a corresponding first public key component is generated. The SM2 algorithm can be used to generate a corresponding second public key component based on the first private key component and elliptic curve basis points. The key management center then sends the first private key component to the client via a secure channel. Furthermore, the key management center can also store the user's first private key component and first public key component locally. This key pair can be stored locally as a key-value pair.

[0036] Upon receiving the private key collaborative generation request, the key generation center generates a second random number and identifies this second random number as the user's second private key component. Based on this second private key component, it generates a corresponding second public key component and sends it to the client via a secure channel. Simultaneously, the key generation center can locally store the user's second private key component and second public key component.

[0037] Next, the client receives the first private key component sent by the key management center and stores it locally. This allows for direct retrieval of the user's first private key component during subsequent decryption processing, enabling collaborative decryption based on this component. The client also receives the second public key component sent by the key generation center and generates the user's complete public key based on both components. This complete public key is then publicly disclosed as the user's encryption key. When other users wish to send encrypted messages to this user, they can use the user's complete public key to encrypt the plaintext message and send the corresponding ciphertext to the client.

[0038] Specifically, the process of generating a user's complete public key based on the first private key component and the second public key component can be as follows: determine the elliptic curve scalar product value of the first private key component and the second public key component, obtain the first difference between the elliptic curve scalar product value and the base point of the elliptic curve, and determine the first difference as the user's complete public key.

[0039] As described above, in the process of generating a user's complete public key, the client generates the key by combining the first private key component provided by the key management center and the second public key component provided by the key generation center. The user's complete private key always exists in fragments at each execution end and is not explicitly assembled.

[0040] In addition, to prevent attackers from retrieving or piecing together the user's complete private key by intercepting the private key components during transmission, in one optional embodiment, when generating the user's complete private key, a complete private key with a non-linear mapping relationship is generated based on the first private key component and the second private key component. This makes it impossible to directly obtain the user's complete private key by linearly superimposing or simply concatenating the first private key component generated by the key management center and the second private key component generated by the key generation center.

[0041] For example, suppose the first private key component is d1, and the second private key component is... The ellipse base point multiplied by its second private key component is That is, the second public key component is Based on the elliptic curve discrete logarithm problem, the second private key component d2 cannot be inversely calculated from the second public key component P2. Therefore, under this constraint, the user's key pair is constructed, i.e., the generated complete user public key is... The corresponding complete private key is .

[0042] However, because the client generates the user's complete public key based solely on the locally stored first private key component d1 and second public key component P2, the client cannot access the second private key component d2 held by the key generation center. Furthermore, the second private key component d2 cannot be derived from the second public key component P2 alone. Therefore, the client cannot reverse-engineer and assemble the user's complete private key using only the first private key component d1 and the second public key component P2. In other words, the client lacks all the parameters needed to generate the complete private key, thus eliminating the risk of the complete private key being leaked on the client side at the source.

[0043] Once the client generates the corresponding user's complete public key during the key registration phase, it can publicly disclose the user's complete public key as the user's encryption key, so that other clients can encrypt plaintext messages based on the user's complete public key to obtain the corresponding ciphertext to be decrypted, and send the ciphertext to be decrypted to the client.

[0044] Specifically, a random number is generated. Based on this random number and the elliptic curve base point, a first elliptic curve point is calculated and determined as the temporary public key. A second elliptic curve point is then generated based on this random number and user a's complete public key. A derived function is called to generate a derived key based on the plaintext length of the plaintext message m to be encrypted and the second elliptic curve point. Based on this derived key and the plaintext message to be encrypted, the ciphertext is generated. Then, a cryptographic hash function is called to generate a hash value based on the second elliptic curve point and the plaintext message to be encrypted. Finally, based on the temporary public key, the ciphertext, and the hash value, the ciphertext to be decrypted is generated. This ciphertext to be decrypted is sent to the client corresponding to user a.

[0045] Once the client receives the ciphertext to be decrypted, it can display the ciphertext on the client side so that the user can determine whether to proceed with decryption. When the user triggers a decryption request for the ciphertext, it verifies whether the temporary public key in the ciphertext is a non-infinity point on an elliptic curve. If the verification passes, the user's first private key component is obtained, and the temporary public key is bound to it to generate the first decryption parameter. Then, the first decryption parameter is sent to the key generation center.

[0046] After receiving the first decryption parameter, the key generation center verifies its validity and uses the user's second private key component to perform co-key processing on the first decryption parameter to obtain the second decryption parameter. Then, the key generation center sends the second decryption parameter to the client via a secure channel.

[0047] After receiving the second decryption parameter, the client determines a shared keypoint based on this parameter and the temporary public key in the ciphertext to be decrypted. The client then decrypts the ciphertext message within the ciphertext to be decrypted using the shared keypoint, obtaining a candidate plaintext message. Next, a message authentication code is generated based on the candidate plaintext message and the shared keypoint. If this message authentication code matches the hash value in the ciphertext to be decrypted, the candidate plaintext message is determined as the plaintext message corresponding to the ciphertext to be decrypted.

[0048] In summary, in this embodiment, by having a key management center generate and securely hold a portion of the target user's private key, and a key generation center generate and hold a portion of the target user's private key, the client only obtains the required first private key portion from the key management center. This ensures that the user's complete private key never appears in plaintext form with any single entity. Furthermore, when there is a regulatory need, the corresponding private key portions can be obtained from both the key management center and the key generation center to obtain the user's complete private key for regulatory purposes. Simultaneously, the first decryption parameter generated by the client can be obtained from the key generation center. Without further user involvement, the decryption process can be reconstructed using only the historical first decryption parameter and the second decryption parameter held by the key generation center itself, thus recovering the plaintext message and meeting the needs for legitimate regulatory oversight and emergency recovery of encrypted data. Additionally, when the target user and the key generation center collaborate on decryption, the target user verifies the first ciphertext portion of the ciphertext to be encrypted, and the key generation center verifies the first intermediate shared point generated by the target user during the decryption process. This means the ciphertext undergoes double validity verification by both parties, preventing the tampered ciphertext from being decrypted and ensuring data confidentiality.

[0049] To facilitate understanding of the specific process of collaborative decryption between the client and the key generation center, combined with... Figure 2 The specific process of collaborative decryption performed by the client is illustrated by an example.

[0050] Figure 2 A flowchart of a two-party collaborative decryption method provided in this application embodiment; as follows: Figure 2 As shown, this method is applied to the client side, and specifically, the method may include the following steps: 201. In response to a user's decryption request for the ciphertext to be decrypted, verify whether the temporary public key in the ciphertext to be decrypted is a non-infinity point on an elliptic curve.

[0051] 202. If the verification is successful, the temporary public key is bound to the user's first private key component to generate the first decryption parameter. The first private key component is generated and distributed to the client by the key management center during the user registration phase.

[0052] 203. Send the first decryption parameter to the key generation center so that the key generation center can verify the validity of the first decryption parameter and use the user's second private key component held by it to perform collaborative key processing on the first decryption parameter to obtain the second decryption parameter.

[0053] 204. Determine the shared key point based on the second decryption parameter and the temporary public key.

[0054] 205. Based on the shared key point, decrypt the ciphertext of the message in the ciphertext to be decrypted to obtain the candidate plaintext message.

[0055] 206. Generate a message authentication code based on the candidate plaintext message and the shared key point. If the message authentication code matches the hash value in the ciphertext to be decrypted, then the candidate plaintext message is determined as the plaintext message corresponding to the ciphertext to be encrypted.

[0056] In practical applications, when a client receives a decryption request triggered by a user for the ciphertext to be decrypted, it responds by verifying whether the temporary public key in the ciphertext is a non-infinity point on an elliptic curve. That is, before performing decryption, the client performs a pre-verification process, which can directly intercept illegal ciphertext before the decryption interaction, identify malicious data without interacting with the key generation center, reduce network interaction overhead, improve decryption concurrency processing capabilities, and ensure that the decryption process conforms to the SM2 standard specification.

[0057] The specific implementation process for verifying the temporary public key can be as follows: first, extract the bit string corresponding to the temporary public key from the ciphertext to be decrypted. and on After performing data type conversion, verify. Is it an elliptic curve? A non-infinite point on the horizon.

[0058] Once it is verified that the bit string corresponding to the temporary public key is a non-infinite point on the elliptic curve E, the user's first private key component is obtained. Since the user's first private key component generated by the key management center has already been stored locally on the client during the key registration phase, it can be directly retrieved from local storage and used to perform collaborative decryption operations.

[0059] To avoid the risk of private key components being intercepted or tampered with during the interaction, when performing collaborative decryption, the temporary public key can first be bound to the first private key component to generate the first decryption parameter. The first decryption parameter is then sent to the key generation center so that the key generation center can verify its validity and use the user's second private key component held by the key generation center to perform collaborative key processing on the first decryption parameter to obtain the second decryption parameter.

[0060] Furthermore, in specific implementation, one optional approach to this private key binding process is to obtain the first product value of the first private key component and the temporary public key, and then determine this first product value as the first decryption parameter. For example, assuming the first private key component is d1, and the temporary public key in the ciphertext to be decrypted is... First, obtain the first product value of the first private key component and the temporary public key. And this first product value is determined as the first decryption parameter. That is, the first decryption parameter is .

[0061] As described above, the first decryption parameter, as an intermediate parameter, carries temporary public key information after being processed by the user's first private key component, but does not contain any plaintext or reversible form of the first private key component itself. Thus, during the interaction with the key generation center, even if the first decryption parameter is intercepted by a third party, it is impossible to deduce the user's first private key component. This effectively prevents private key leakage and man-in-the-middle attacks while ensuring the decryption function.

[0062] After the client receives the second decryption parameter sent by the key generation center, it determines a shared keypoint based on the second decryption parameter and the temporary public key. Then, based on the shared keypoint, it decrypts the ciphertext in the ciphertext to be decrypted to obtain a candidate plaintext message. Specifically, in an optional embodiment, a second difference between the second decryption parameter and the temporary public key is determined, and this second difference is used as the shared keypoint. Based on the shared keypoint, a key derivation function is called to generate a derived key with a length equal to the length of the plaintext message corresponding to the ciphertext to be encrypted. Based on the derived key, the ciphertext in the ciphertext to be decrypted is decrypted to obtain a candidate plaintext message.

[0063] Continuing with the example above, suppose the second decryption parameter is... The determined second decryption parameter and the second difference between the temporary public key are: The second difference is determined as the shared key point. That is, the shared key point is Then, the derived function is called to generate the derived key. ,in, This represents the length of the plaintext message corresponding to the ciphertext to be decrypted. The derived key is used to cipher the message. Decryption is performed to obtain candidate plaintext messages. .

[0064] Next, a message authentication code is generated based on the candidate plaintext message and the shared key point. If the message authentication code matches the hash value in the ciphertext to be decrypted, the candidate plaintext message is determined as the plaintext message corresponding to the ciphertext to be decrypted. Specifically, when generating the message authentication code, a cryptographic hash function can be called to generate the message authentication code based on the candidate plaintext message and the shared key point. If the message authentication code matches the hash value in the ciphertext to be decrypted... Equal, that is Then the candidate plaintext message The plaintext message corresponding to the decrypted ciphertext has been identified.

[0065] In summary, in this embodiment, the client uses the first private key component generated and stored by the key management center to generate the first decryption parameter. The key generation center uses the second private key component it holds and the first decryption parameter sent by the client to generate the second decryption parameter. The client then reconstructs the shared key point based on the second decryption parameter to recover the plaintext message corresponding to the ciphertext to be decrypted. That is, in this collaborative decryption process, the plaintext message can be recovered through only one round of decryption parameter exchange, without directly exposing or combining the private key components, thus avoiding the risk of interception or tampering during the private key component interaction. Furthermore, since the client submits the first decryption parameter to the key generation center each time it decrypts, the key generation center can selectively record these values. In this way, in a legitimate authorization scenario, the user does not need to participate again. The decryption process can be reconstructed based solely on the historical first decryption parameter and the second decryption parameter held by the key generation center itself to recover the plaintext message. Thus, the legitimate supervision and emergency recovery requirements of encrypted data can be met without weakening the original security. In addition, during the collaborative decryption process, the collaborative decryption process continues only if both the client verifies the temporary public key and the key generation center verifies the first decryption parameter. This double validity verification by both parties prevents the tampered ciphertext from being decrypted, further ensuring data confidentiality.

[0066] The above embodiments describe the specific implementation process of collaborative decryption performed by the client. The following describes the specific implementation process of collaborative decryption performed by the key generation center from the perspective of the key generation center.

[0067] Figure 3 A flowchart of another two-party collaborative decryption method provided in the embodiments of this application; as follows: Figure 3As shown, this method is applied to a key generation center that collaborates with clients for decryption. Specifically, the method may include the following steps: 301. Receive the first decryption parameter sent by the client. The first decryption parameter is obtained by binding the temporary public key to the private key based on the first private key component held by the client, after the temporary public key in the ciphertext to be decrypted has been verified.

[0068] 302. Perform elliptic curve point validity verification on the first decryption parameter. If the verification passes, use the user's second private key component to perform collaborative key processing on the first decryption parameter to obtain the second decryption parameter.

[0069] 303. Send the second decryption parameter to the client so that the client can determine the shared key point based on the second decryption parameter and the temporary public key, and decrypt the message ciphertext in the ciphertext to be decrypted based on the shared key point to obtain the candidate plaintext message. If the message authentication code generated based on the candidate plaintext message and the shared key point matches the hash value in the ciphertext to be decrypted, then the candidate plaintext message is determined as the plaintext message corresponding to the ciphertext to be decrypted.

[0070] In practical applications, after the key generation center receives the first decryption parameter sent by the client, it performs an elliptic curve point validity verification on the first decryption parameter to prevent malicious users from submitting forged first decryption parameters (such as non-curve points or points at infinity) that could lead to server malfunctions or information leaks.

[0071] After the first decryption parameter is verified, the user's second private key component stored locally at the key generation center is used to perform collaborative key processing on the first decryption parameter to obtain the second decryption parameter. Specifically, one optional implementation method for collaborative key processing is to obtain the product value of the second private key component and the first decryption parameter, and determine the product value as the second decryption parameter.

[0072] For example, suppose the second private key component is d2, and the first decryption parameter is... The product of the obtained second private key component and the first decryption parameter is... The product value is determined as the second decryption parameter. In other words, the second decryption parameter acts as an intermediate parameter, carrying temporary public key information after being processed by the user's second private key component, but does not contain any plaintext or reversible form of the second private key component itself. Thus, during the interaction with the client, even if the second decryption parameter is intercepted by a third party, it is impossible to deduce the user's second private key component. This effectively prevents private key leakage and man-in-the-middle attacks while ensuring the decryption function.

[0073] Then, the second decryption parameter is sent to the client so that the client can determine the shared key point based on the second decryption parameter and the temporary public key, and decrypt the message ciphertext in the ciphertext to be decrypted based on the shared key point to obtain the candidate plaintext message. If the message authentication code generated based on the candidate plaintext message and the shared key point matches the hash value in the ciphertext to be decrypted, the candidate plaintext message is determined as the plaintext message corresponding to the ciphertext to be decrypted.

[0074] The specific implementation process involved in the embodiments of this application can be referred to the content of the above embodiments, and will not be repeated here.

[0075] In summary, in this embodiment, the client uses a first private key component generated and stored by the key management center to generate a first decryption parameter. The key generation center uses its second private key component and the first decryption parameter sent by the client to generate a second decryption parameter. The client then reconstructs the shared key point based on the second decryption parameter to recover the plaintext message corresponding to the ciphertext to be decrypted. This collaborative decryption process recovers the plaintext message through only one round of decryption parameter exchange, without directly exposing or combining private key components, thus avoiding the risk of interception or tampering during private key component interaction. Furthermore, since the user's complete private key is generated and stored by both the key management center and the key generation center, it can be obtained from them when regulatory oversight is required. Each time the client decrypts, it submits the first decryption parameter to the key generation center, which can selectively record these values. In legitimate authorization scenarios, the user does not need to participate again; the decryption process can be reconstructed using only the historical first decryption parameter and the second decryption parameter held by the key generation center itself to recover the plaintext message. Therefore, without weakening the original security, the legitimate regulatory and emergency recovery requirements for encrypted data can be met. In addition, during the collaborative decryption process, the collaborative decryption process continues only if both the client verifies the temporary public key and the key generation center verifies the first decryption parameter. This double validity verification by both parties prevents the tampered ciphertext from being decrypted, further ensuring data confidentiality.

[0076] To facilitate understanding of the above two-party collaborative decryption process, an example of the two-party collaborative decryption process in a specific application scenario is provided.

[0077] In practical applications, before client A collaborates with the key generation center to decrypt, client A can pre-apply for its corresponding complete public key to be publicly disclosed as its encryption key. This allows other clients to encrypt plaintext messages to be encrypted based on the complete public key disclosed by client A, and then send the encrypted ciphertext to be decrypted to client A.

[0078] In practice, client A first sends a private key collaborative generation request to the Key Management Center (KMC) and the Key Generation Center (KGC) for collaborative decryption. Upon receiving this request, the Key Management Center generates a first random number as the user's first private key component, generates a corresponding first public key component based on this first private key component, and sends the first private key component to the client via a secure channel.

[0079] Specifically, generate the first random number d1 And calculate the points of the elliptic curve. This is designated as the first public key component, meaning the generated client key pair is... The first private key component d1 is sent to client a via a secure channel.

[0080] Similarly, when the key generation center receives the private key collaborative generation request, it generates a second random number as the user's second private key component, generates a second public key component based on the second private key component, and sends the second key component to client a.

[0081] Specifically, the key generation center generates a second random number d2. Calculate the points on the elliptic curve. This is designated as the second public key component, meaning the key pair corresponding to the generated key generation center is... The second public key component P2 is sent to client a.

[0082] After receiving the first private key component and the second public key component, client A determines the elliptic curve scalar product of the first private key component and the second public key component, and obtains the first difference between the elliptic curve scalar product value and the base point of the elliptic curve; this first difference is then used as the user's complete public key. Specifically, Furthermore, in practical applications, both the key pair corresponding to the client and the key pair corresponding to the key generation center can be generated by the key management center. The key management center generates both the key pair corresponding to the client and the key pair corresponding to the key generation center, and sends the generated client-side key pair to client A, as well as the generated key pair corresponding to the key generation center, to the key generation center. Upon receiving a private key collaborative generation request from client A, the key generation center sends the second public key component of its key pair to client A. Predefined operations can be performed on the client-side key pair and the key pair corresponding to the key generation center to generate the user's complete private key and complete public key. Specifically, the Key Management Center (KMC) receives the response and generates a random number d1. And calculate the points of the elliptic curve. That is, the user's key pair is Furthermore, the key management center (KMC) sends the first private key component d1 to client a via a secure channel. Simultaneously, the key management center (KMC) generates a random number d2. Calculate the points on the elliptic curve. That is, the key pair corresponding to the key generation center is The user sends the second private key component d2 and the second public key component P2 to the key generation center KGC. The key generation center KGC receives the response and sends P2 to the client a. The user and the key generation center KGC then calculate the elliptic curve points. That is, user A's complete public key is PA.

[0083] Then, client a publishes the complete public key PA as the encryption key.

[0084] When client b wants to send an encrypted message to client a, it obtains client a's complete public key PA, and uses PA to perform SM2 encryption on the message m to be encrypted, obtaining the corresponding ciphertext c to be decrypted. Send to client a.

[0085] Specifically, client b generates random numbers. Calculate the points of the elliptic curve Then, calculate ,in It is the key delivery function. This is the plaintext length. Generate ciphertext. ,generate Finally, the ciphertext to be decrypted... Send to client a.

[0086] After receiving the ciphertext to be decrypted, client A can display it on its client. When a user triggers a decryption request through the client, client A responds to the decryption request and retrieves the ciphertext from the client. Extract bit string and on After data type conversion, verify the temporary public key in the ciphertext to be decrypted. Is it a non-infinity point on an elliptic curve?

[0087] When the temporary public key is verified For a non-infinity point on an elliptic curve, client a uses its first private key component. and temporary public key Determine the first decryption parameter The first decryption parameter is then sent to the key generation center for collaborative decryption. Upon receiving the first decryption parameter, the key generation center performs an elliptic curve point validity verification. If the verification passes, it uses its second private key component and the first decryption parameter to determine the second decryption parameter. And send the second decryption parameter to client a.

[0088] After receiving the second decryption parameter, client A determines the second difference between the second decryption parameter and the temporary public key. The second difference is then used as the shared key point. Based on the shared key point, the key derivation function is called to generate a derived key with a length equal to the length of the plaintext message corresponding to the ciphertext to be decrypted. The derived key is used to decrypt the ciphertext of the message within the ciphertext. Decryption is performed to obtain candidate plaintext messages. And verify. If the verification passes, plaintext will be output. .

[0089] In summary, in this embodiment, the first and second private key components are held by two types of professional key trusted entities: the Key Management Center (KMC) and the Key Generation Center (KGC). This aligns with cryptographic regulatory requirements, and neither the two professional key trusted entities nor the client can obtain the complete private key. Simultaneously, it meets the computational requirements for collaborative decryption, prevents private key leakage, and ensures data security and decryption reliability. Furthermore, the client only obtains a partial private key component, which, combined with the KGC's public elliptic curve points, generates a unique corresponding complete public key. If either entity is compromised, the complete private key cannot be recovered. Moreover, during collaborative decryption, dual ciphertext validity verification is employed, and the decryption process specifically removes interference introduced by the temporary public key, restores the SM2 shared key parameters (a national cryptographic standard), strictly follows the national cryptographic algorithm flow, and conforms to the SM2 standard collaborative decryption process. The entire process strictly adheres to the SM2 algorithm specification; ciphertext verification, intermediate result calculation, plaintext recovery, and verification steps are all compatible with the SM2 standard decryption process, ensuring decryption correctness and system compatibility.

[0090] The following describes in detail one or more embodiments of a two-party collaborative decryption apparatus according to this application. Those skilled in the art will understand that these apparatuses can be configured using commercially available hardware components through the steps taught in this solution.

[0091] Figure 4 This is a schematic diagram of the structure of a two-party collaborative decryption device provided in an embodiment of this application, applied to a client, such as... Figure 4 As shown, the device includes: a response module 11, a processing module 12, a sending module 13, a determining module 14, a decryption module 15, and a generating module 16.

[0092] The response module 11 is used to respond to a decryption request triggered by a user for the ciphertext to be decrypted and to verify whether the temporary public key in the ciphertext to be decrypted is a non-infinity point on an elliptic curve.

[0093] The processing module 12 is used to perform private key binding processing on the temporary public key based on the user's first private key component if the verification is successful, and generate a first decryption parameter; the first private key component is generated and distributed to the client by the key management center during the user registration stage.

[0094] The sending module 13 is used to send the first decryption parameter to the key generation center so that the key generation center can verify the validity of the first decryption parameter and use the user's second private key component held by it to perform collaborative key processing on the first decryption parameter to obtain the second decryption parameter.

[0095] The determination module 14 is used to determine the shared key point based on the second decryption parameter and the temporary public key.

[0096] The decryption module 15 is used to decrypt the message ciphertext in the ciphertext to be decrypted based on the shared key point to obtain the candidate plaintext message.

[0097] The generation module 16 is used to generate a message authentication code based on the candidate plaintext message and the shared key point. If the message authentication code matches the hash value in the ciphertext to be decrypted, the candidate plaintext message is determined as the plaintext message corresponding to the ciphertext to be decrypted.

[0098] Optionally, the response module 11 is further configured to: in response to a private key collaborative generation request triggered by a user, forward the private key collaborative generation request to the key management center, so that the key management center generates a first random number as the user's first private key component, generates a corresponding first public key component based on the first private key component, and sends the first private key component to the client through a secure channel; forward the private key collaborative generation request to the key generation center, so that the key generation center generates a second random number as the user's second private key component, generates a second public key component based on the second private key component, and sends the second key component to the client; generate the user's complete public key based on the first private key component and the second public key component, and publish the user's complete public key as the user's encrypted public key.

[0099] Optionally, the response module 11 is further configured to: determine the elliptic curve scalar product value of the first private key component and the second public key component; obtain the first difference between the elliptic curve scalar product value and the base point of the elliptic curve; and determine the first difference as the complete public key of the user.

[0100] Optionally, the processing module 12 is specifically used to: obtain the first product value of the first private key component and the temporary public key; and determine the first product value as the first decryption parameter.

[0101] Optionally, the determining module 14 is specifically used to: determine a second difference between the second decryption parameter and the temporary public key, and determine the second difference as a shared key point.

[0102] Optionally, the decryption module 15 is specifically used to: based on the shared key point, call the key derivation function to generate a derived key with a length equal to the length of the plaintext message corresponding to the ciphertext to be decrypted; and decrypt the message ciphertext in the ciphertext to be decrypted based on the derived key to obtain a candidate plaintext message.

[0103] Figure 4 The device shown can perform the steps described in the foregoing embodiments. For detailed execution process and technical effects, please refer to the description in the foregoing embodiments, which will not be repeated here.

[0104] In one possible design, the above Figure 4 The structure of the two-party collaborative decryption device shown can be implemented as an electronic device, such as... Figure 5 As shown, the electronic device may include: a memory 21, a processor 22, and a communication interface 23. The memory 21 stores executable code, which, when executed by the processor 22, enables the processor 22 to at least implement the two-party collaborative decryption method executed by the client as provided in the foregoing embodiments.

[0105] Figure 6 This is a schematic diagram of another two-party collaborative decryption device provided in an embodiment of this application, applied to a key generation center for collaborative decryption with a client, such as... Figure 6 As shown, the device includes: a receiving module 31, a processing module 32, and a transmitting module 33.

[0106] The receiving module 31 is used to receive the first decryption parameter sent by the client. The first decryption parameter is obtained by binding the temporary public key to the temporary public key based on the first private key component held by the client, after the temporary public key in the ciphertext to be decrypted has been verified.

[0107] The processing module 32 is used to perform elliptic curve point validity verification on the first decryption parameter. If the verification is successful, it uses the user's second private key component to perform collaborative key processing on the first decryption parameter to obtain the second decryption parameter.

[0108] The sending module 33 is configured to send the second decryption parameter to the client, so that the client determines a shared key point based on the second decryption parameter and the temporary public key, and decrypts the message ciphertext in the ciphertext to be decrypted based on the shared key point to obtain a candidate plaintext message. If the message authentication code generated based on the candidate plaintext message and the shared key point matches the hash value in the ciphertext to be decrypted, then the candidate plaintext message is determined as the plaintext message corresponding to the ciphertext to be decrypted.

[0109] Optionally, the receiving module 31 is further configured to: receive a private key collaborative generation request sent by the client, generate a random number as the user's second private key component; generate a second public key component based on the second private key component; store the second private key component and the second public key component locally, and send the second public key component to the client, so that the client generates the user's complete public key based on the first private key component and the second public key component generated by the key management center, and publishes the user's complete public key as the user's encrypted public key.

[0110] Optionally, the processing module 32 is specifically used to: obtain the product value of the second private key component and the first decryption parameter; and determine the product value as the second decryption parameter.

[0111] Figure 6 The device shown can perform the steps described in the foregoing embodiments. For detailed execution process and technical effects, please refer to the description in the foregoing embodiments, which will not be repeated here.

[0112] In one possible design, the above Figure 6 The structure of the two-party collaborative decryption device shown can be implemented as an electronic device, such as... Figure 7 As shown, the electronic device may include: a processor 41, a memory 42, and a communication interface 43. The memory 42 stores executable code, which, when executed by the processor 41, enables the processor 41 to at least implement the two-party collaborative decryption method performed by the server as provided in the foregoing embodiments.

[0113] Furthermore, this application embodiment also provides a non-transitory machine-readable storage medium storing executable code, which, when executed by a processor of an electronic device, enables the processor to at least implement the two-party collaborative decryption method provided in the foregoing embodiments.

[0114] In addition, this application also provides a computer program product, which includes a computer program or instructions that, when executed by a processor, enable the processor to implement the steps in the above method embodiments. It should be understood that each step or combination of steps in the above method flow can be implemented by a computer program or instructions.

[0115] In addition, these computer programs or instructions can be applied to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device, so that the processor of the general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device can be implemented as a means to implement the corresponding functions in the above method embodiments.

[0116] The device embodiments described above are merely illustrative, and the units described as separate components may or may not be physically separate. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0117] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of a necessary general-purpose hardware platform, or by a combination of hardware and software. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a computer product. This application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0118] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A two-party collaborative decryption method, characterized in that, Applied to a client, the method includes: In response to a user's decryption request for the ciphertext to be decrypted, verify whether the temporary public key c1 in the ciphertext to be decrypted is a non-infinity point on an elliptic curve. If the verification is successful, the temporary public key is bound to the user's first private key component to generate a first decryption parameter; the first private key component is a first random number generated and distributed to the client by the key management center during the user registration phase. The first decryption parameter is sent to the key generation center so that the key generation center can verify the validity of the first decryption parameter and use the user's second private key component held by it to perform collaborative key processing on the first decryption parameter to obtain the second decryption parameter. The second private key component is a second random number generated by the key generation center. Determine the shared key point based on the second decryption parameter and the temporary public key; Based on the shared key point, the ciphertext in the ciphertext to be decrypted is decrypted to obtain the candidate plaintext message; A message authentication code is generated based on the candidate plaintext message and the shared key point. If the message authentication code matches the hash value in the ciphertext to be decrypted, then the candidate plaintext message is determined as the plaintext message corresponding to the ciphertext to be decrypted.

2. The method according to claim 1, characterized in that, The method further includes: In response to a user-triggered private key collaborative generation request, the private key collaborative generation request is forwarded to the key management center, so that the key management center generates a first random number as the user's first private key component, generates a corresponding first public key component based on the first private key component, and sends the first private key component to the client through a secure channel; The private key collaborative generation request is forwarded to the key generation center, so that the key generation center generates a second random number as the user's second private key component, generates a second public key component based on the second private key component, and sends the second public key component to the client; Based on the first private key component and the second public key component, the user's complete public key is generated, and the user's complete public key is published as the user's encrypted public key.

3. The method according to claim 2, characterized in that, The step of generating the user's complete public key based on the first private key component and the second public key component includes: Determine the elliptic curve scalar product of the first private key component and the second public key component; Obtain the first difference between the scalar product value of the elliptic curve and the base point of the elliptic curve; The first difference is determined as the user's complete public key.

4. The method according to claim 1, characterized in that, The step of binding the temporary public key with the first private key component to generate the first decryption parameter includes: Obtain the first product value of the first private key component and the temporary public key; The first product value is determined as the first decryption parameter.

5. The method according to claim 1, characterized in that, The step of determining the shared key point based on the second decryption parameter and the temporary public key includes: Determine the second difference between the second decryption parameter and the temporary public key, and determine the second difference as the shared key point; The step of decrypting the ciphertext in the ciphertext to be decrypted based on the shared key point to obtain candidate plaintext messages includes: Based on the shared key point, the key derivation function is called to generate a derived key with a length equal to the length of the plaintext message corresponding to the ciphertext to be decrypted; Based on the derived key, the message ciphertext in the ciphertext to be decrypted is decrypted to obtain the candidate plaintext message.

6. A two-party collaborative decryption method, characterized in that, A key generation center used for collaborative decryption with clients, the method includes: The system receives a first decryption parameter sent by the client. This first decryption parameter is obtained by binding the temporary public key to the temporary public key based on the first private key component held by the client, after the temporary public key in the ciphertext to be decrypted has been verified. The first private key component is a first random number generated and distributed to the client by the key management center during the user registration phase. The validity of the first decryption parameter is verified by elliptic curve points. If the verification is successful, the first decryption parameter is processed by a collaborative key using the second private key component held by the user to obtain the second decryption parameter. The second private key component is a second random number generated by the key generation center. The second decryption parameter is sent to the client so that the client determines a shared key point based on the second decryption parameter and the temporary public key, and decrypts the ciphertext in the ciphertext to be decrypted based on the shared key point to obtain a candidate plaintext message. If the message authentication code generated based on the candidate plaintext message and the shared key point matches the hash value in the ciphertext to be decrypted, then the candidate plaintext message is determined as the plaintext message corresponding to the ciphertext to be decrypted.

7. The method according to claim 6, characterized in that, The method further includes: Receive the private key collaborative generation request sent by the client, and generate a random number as the user's second private key component; Generate a second public key component based on the second private key component; The second private key component and the second public key component are stored locally, and the second public key component is sent to the client, so that the client generates the user's complete public key based on the first private key component and the second public key component generated by the key generation center, and publishes the user's complete public key as the user's encrypted public key.

8. The method according to claim 6, characterized in that, The step of using the user's second private key component to perform collaborative key processing on the first decryption parameter to obtain the second decryption parameter includes: Obtain the product of the second private key component and the first decryption parameter; The product value is determined as the second decryption parameter.

9. An electronic device, characterized in that, include: The system includes a memory, a processor, and a communication interface; wherein the memory stores executable code, which, when executed by the processor, causes the processor to perform the two-party collaborative decryption method as described in any one of claims 1 to 5 or 6 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor of an electronic device, causes the processor to perform the two-party collaborative decryption method as described in any one of claims 1 to 5 or 6 to 8.

Images