A publicly verifiable private key escrow and threshold recovery method

Abstract

This invention proposes a publicly verifiable private key escrow and threshold recovery method, relating to the fields of cryptography, key management, and threshold recovery. The method involves a group of participants performing distributed key generation to obtain private key shares, public key shares, and a joint public key. During the escrow phase, the participants generate a ciphertext object identifier, an internal random seed, a public seed label, and a coordinated transcription using a distributed random number generation protocol with session locking. The ciphertext object identifier is then injected into the key derivation, digest calculation, and challenge string generation processes. The key owner constructs a two-track ciphertext, encrypting a random value and a response value formed by the random value and the private key to be escrowed. A binding digest and challenge string are then generated to form publicly verifiable ciphertext. During recovery, the authorized recovery end regenerates the seed under the same ciphertext object identifier constraint and decrypts the two-track ciphertext to recover the private key to be escrowed. This method improves the public verifiability, security, and auditability of private key escrow.

Description

Technical Field

[0001] This invention relates to the fields of cryptography, key management and threshold recovery, specifically a publicly verifiable private key escrow and threshold recovery method. Background Technology

[0002] With the widespread deployment of cloud computing, blockchain, IoT, and cross-domain zero-trust infrastructure, high-value cryptographic materials such as user private keys, institutional master keys, and device identity keys increasingly face the practical need for long-term secure storage. The permanent loss of a private key will irrevocably invalidate the corresponding digital assets, encrypted data, or identity credentials; however, storing private keys on a single device or entity poses risks such as single points of failure, physical damage, and internal threats. Entrusting private keys to multiple parties in encrypted form for safekeeping, and enabling threshold participants to collaboratively trigger recovery when necessary, has become a core security requirement in these scenarios.

[0003] The existing technologies mainly involve the following types of solutions.

[0004] The first category is traditional secret sharing and verifiable secret sharing techniques. This type of scheme splits the secret into multiple parts and distributes them to participants, allowing at least a threshold number of participants to reconstruct the original secret. Participants can also verify whether the received shares were correctly generated by an honest distributor. However, the core object of this type of scheme is the secret share itself; it cannot directly provide an encrypted ciphertext object for long-term cloud storage. External auditors also cannot check the consistency between the ciphertext and the target public key without holding any shares.

[0005] The second category is publicly verifiable private key escrow technology. This type of scheme, through a dual-track ciphertext structure and interleaved opening mechanism, allows the public verifier to check whether the ciphertext correctly encodes the private key corresponding to the target public key without obtaining the private key. Representative schemes based on a single recovery key or local key derivation method involve the user locally selecting a random seed to deterministically derive all temporary keys. While the public verification mechanism is complete, the recovery path is entirely determined by this single seed, failing to meet the security requirement of multi-participant threshold-triggered recovery. In other words, the holder of a single recovery key can independently complete the recovery, rendering the threshold constraint ineffective.

[0006] The third category is collaborative key management technology based on distributed key generation and threshold signatures. This type of scheme distributes private key shares among multiple participants, making compromises by a few insufficient to recover the complete private key or forge a signature. However, this type of scheme deals with signing or decryption capabilities and does not directly generate a private key ciphertext object that can be held indefinitely. Furthermore, publicly disclosed third parties cannot independently audit the ciphertext content without participating in the protocol.

[0007] The fourth category combines threshold-based distributed random number generation with private key escrow. This type of scheme uses a random seed collaboratively generated by participating parties that meet threshold conditions to drive temporary key derivation. This makes the recovery path dependent on threshold collaboration rather than a single recovery key, offering superior security compared to the second category. However, this type of scheme suffers from three pain points in engineering practice that have not yet been effectively addressed by existing technologies.

[0008] First, coordinated transcription and ciphertext objects lack a one-way binding mechanism. In escrow schemes based on threshold distributed random number generation, coordinated transcription records the process parameters of the participants collaboratively generating a random seed. However, existing schemes do not establish an unbreakable binding between coordinated transcription and the unique identifier of a specific ciphertext object. If the coordinated transcription does not contain a unique identifier for the ciphertext object, theoretically, the same coordinated transcription could be used in the recovery process of different ciphertext objects, or the derived tag of the internal random seed could be associated with an incorrect ciphertext object, causing the recovery end to unknowingly map the correct seed material to another ciphertext object. Simultaneously, if the seed-based temporary key derivation and open digest computation are not injected with the ciphertext object identifier, different ciphertext objects may generate the same temporary key or digest, thus raising the risk of cross-object reuse. Existing publicly verifiable escrow schemes lack specific protection designs against these issues.

[0009] Secondly, there is the problem of recovery path disruption caused by the liveness dependency of the coordinator. In threshold distributed random number generation protocols, the coordinator is responsible for generating the coordination challenge group element, and the other participants calculate their respective threshold responses based on this element. If the coordinator goes offline after writing the coordination challenge group element into the public transcription but before the protocol is completed, subsequent processing faces a dilemma: if the backup party is allowed to regenerate the coordination challenge group element, the encryption and recovery phases will not be able to aggregate the same internal random seed based on the same coordination challenge group element, resulting in a permanent break in the recovery path; if regeneration is not allowed, the protocol cannot continue without a backup switching mechanism. Existing solutions either require the coordinator to remain online until the entire protocol is completed, forming a strong liveness dependency, or reinitialize the coordination process during backup switching, disrupting the deterministic consistency of the encryption and recovery phases.

[0010] Furthermore, changes in the participant set can permanently deactivate escrowed ciphertext. The storage period for escrowed ciphertext often spans months or even years. During this time, participants may leave or be replaced due to reasons such as staff departures, hardware damage, key share leaks, or organizational restructuring. Once the number of available participants in the current participant set falls below the original threshold, the recovery conditions based on the original coordinated transcription will be permanently unsatisfactory, and the escrowed ciphertext will effectively become inactive. Existing threshold key escrow schemes are designed under the assumption that the participant set remains statically unchanged. They lack both a formal framework for handling scenarios involving dynamic changes in the participant set and a supporting mechanism for maintaining the recoverability of the ciphertext. The public verifier cannot perceive historical changes in the participant set at the ciphertext object level and has no way of determining whether the current ciphertext is still in a recoverable state.

[0011] In summary, existing technologies, in their integrated solutions for private key ciphertext escrow, threshold-triggered recovery, and third-party public verification, have not yet simultaneously addressed three major engineering challenges: the one-way binding between coordinated transcription and ciphertext objects, secure switching without the introduction of new randomness by the coordinated initiator, and the persistent recoverability of ciphertext under dynamic changes in the set of participants. Summary of the Invention

[0012] To address the above problems, this invention proposes a publicly verifiable private key escrow and threshold recovery method, comprising the following steps:

[0013] S1. Initialize system common parameters, the system common parameters including at least those of order [order missing]. Elliptic curve group, group generator Hash function Key derivation function Hash to group function Commitment algorithms and public-key cryptographic components that support replayable open verification. Simultaneously, it generates a global ciphertext object identifier namespace and a session domain delimiter tag set;

[0014] S2. The participating parties execute a distributed key generation protocol to generate private key shares for each participant. Public key shares and joint public key ;

[0015] S3. During the private key escrow phase, a threshold value of not less than [a certain threshold value] is required. The participating parties execute a distributed random number generation protocol with session locking to generate unique ciphertext object identifiers. Internal random seed Public seed tags and publicly coordinated transcription ; wherein, the The coordinated transcription process is determined and written into the coordinated input by the participating parties before the generation of coordinated transcription, so as to enable coordinated transcription. It forms an unbreakable one-way binding with the unique ciphertext object;

[0016] S4. The key owner relies solely on the internal random seed. and the ciphertext object identifier Commonly driving key derivation, for each index Derive two temporary key pairs, and for the private key to be escrowed. Construct a two-track ciphertext, where the first track encrypts a random value. Second-track encrypted response value ;

[0017] S5. The key owner generates a binding digest for the potential open information on both sides of each index position, and generates a challenge string based on the ciphertext transcription containing the target public key, public seed tag, ciphertext object identifier, public coordination transcription, dual-track ciphertext and binding digest; and forms a publicly verifiable ciphertext by publicly revealing only one side of the witness at each index position based on the challenge string.

[0018] S6. The public verifier recalculates the challenge string based on the publicly verifiable ciphertext and checks the open digest, group relation, and ciphertext replayability consistency of the public side according to the challenge string; during the recovery phase, the authorized recovery end parses the ciphertext object identifier from the ciphertext. And it is injected as a domain separation parameter into the coordinated transcriptional reuse process, with a threshold value of not less than [value missing]. The participants in the same Under constraints, the same internal random seed is regenerated. After verifying that the regenerated public seed label is consistent with the public seed label in the ciphertext, the dual-track ciphertext is decrypted and the private key to be managed is recovered.

[0019] Ciphertext object identifier in step S3 Generated in the following way:

[0020] ;

[0021] in The target public key corresponding to the private key to be managed. For this managed session, there are no fewer than An unpredictable session random number jointly generated by several participating parties, the session random number in Once confirmed, it cannot be changed; the stated Before being transmitted to the coordinating initiator, the transcription is jointly witnessed by a subset of participating parties that meet the threshold conditions and is publicly coordinated. Explicit records;

[0022] The distributed random number generation protocol with session locking in step S3 includes:

[0023] The coordinating initiator is selected from the subset of participants that meet the threshold conditions according to publicly known deterministic rules. If the coordinator goes offline after the start of coordination but before the completion of the coordinated transcription, the next participant in the backup coordinator sequence is activated sequentially according to the deterministic rules. The backup coordinator directly reuses the coordination challenge group elements already written into the public transcription. And its proof continues to advance the agreement without the need for regeneration. Other participants do not need to be re-verified. The identity of the generator is verified only. A consistency proof is satisfied for the corresponding public key share; this ensures that replacing the coordinator does not introduce new randomness input, thus not changing the internal random seed. A deterministic recovery path;

[0024] The deterministic rule generates an ordered alternative list from the participant set based on the following sorting function:

[0025] ;

[0026] in The set of participant indices that meet the threshold conditions. This is the counter for the current round; the output of the sorting function is a pseudo-random permutation, allowing all participants to locally compute the complete backup sequence before the protocol begins, and the backup sequence is consistent with... Strongly bound, spare sequences across ciphertext objects are not reusable.

[0027] Internal random seed in step S3 and public seed tags Generate in the following way:

[0028] ; ;

[0029] in The secret group elements are obtained by aggregating Lagrange interpolation among the participants who meet the threshold conditions. Standardize its coding. Injecting the derived function as a domain separator parameter allows different ciphertext objects to correspond to... Even with the same set of participants and the same message input, they cannot be the same; and Not written into public encrypted text, and All are written into public encrypted text;

[0030] The temporary key derivation method in step S4, driven by both the internal random seed and the ciphertext object identifier, is as follows:

[0031] ;

[0032] ;

[0033] Among them, the domain label and Each contains a ciphertext object identifier as context, enabling the same internal random seed to derive different temporary keys under different ciphertext objects, thereby avoiding the reuse of temporary keys across ciphertext objects.

[0034] The dual-track ciphertext in step S4 includes:

[0035] For each index Randomly select random values And the first encryption randomness ,calculate:

[0036] ;

[0037] Calculate response value Randomly select the second encryption randomness ,calculate:

[0038] ;

[0039] The private key to be managed The corresponding public key is ; The public verification party in the challenge series Bit At that time, through inspection:

[0040] ;

[0041] To verify the consistency of the group relationship between the second-track public witness and the target public key, the verification does not require obtaining... , Or any private materials.

[0042] The binding summary in step S5 includes:

[0043] ;

[0044] ;

[0045] The binding digest injects a ciphertext object identifier into the domain separator label. This prevents the open digests under different ciphertext objects from being reused across objects; the binding digest is written into the ciphertext transcription before the challenge string is generated, so as to restrict the ciphertext generator from reselecting the open information after learning of the challenge.

[0046] Challenge string in step S5 Generated from the following transcription hash:

[0047] ;

[0048] in Indicates the first step of extracting the hash output. 1 bit; the challenge string will simultaneously By incorporating hash input, the generation of the challenge string is made inextricably linked to the unique identifier of the ciphertext object.

[0049] When the challenge sequence is Bit At that time, the first The first track witness at each index position ;when At that time, the first The second track witness at each index position Each index location exposes only one side of the witness, preventing public verifiers from simultaneously obtaining witnesses under the same index. and Therefore, it cannot be calculated directly. .

[0050] Public verification party Perform the following three checks:

[0051] ;

[0052] ;

[0053] ;

[0054] Public verification party Perform the following three checks:

[0055] ;

[0056] ;

[0057] ;

[0058] The public verifier does not need to obtain a share of the participants' private keys. Internal random seed Secret Group Elements Undisclosed information or private keys awaiting escrow This allows for the verification of the publicly visible projection of the ciphertext; and all verification inputs during the public verification process are the public parts of the ciphertext object, without relying on any out-of-band secret channels.

[0059] During the recovery phase, the authorized recovery client performs the following steps:

[0060] First, perform a full public verification; after successful verification, parse the encrypted text. and coordinated transcription It is required to be no less than the threshold value. The participants in the domain parameters Constrained reuse The same coordination challenge group elements recorded in the middle Each participant calculates the threshold response. And transmitted through a certified private channel; authorized recovery terminal aggregates the results. ,calculate:

[0061] ;

[0062] ;

[0063] like With the ciphertext If they don't match, reject; if they match, use. and Derive all temporary private keys again and decrypt them separately. and get and ,calculate If all If they match, output the common value as the recovery private key; otherwise, reject the request.

[0064] The method also includes a participant set change adaptation step: when the participant set changes from Change to a new set At that time, a private key share redistribution protocol is executed to ensure that the new set of participants holds the same joint public key. The new private key share is used to coordinate the transcription of already escrowed ciphertext objects. Perform the transcription update operation: The transcription update proof is generated from the intersection subset that simultaneously satisfies the threshold conditions of the old participant set and the new participant set. The public key information of the new participant set and the new threshold parameters are appended to the extended transcription field of the ciphertext object, so that the ciphertext that has been held can still be recovered by the new participant set after the participant set changes, and the authenticity of the extended transcription field can be independently verified by the public verifier.

[0065] The transcriptional update operation includes the following sub-steps:

[0066] Select participants from those that belong to both the old participant set and the new participant set, with a minimum of the old threshold value. Several participants, based on their old private key shares. Re-aggregate to obtain secret group elements It also provides privately verified shares to participants in the new participant set who do not hold old shares, enabling all participants in the new participant set to access shares without obtaining [the necessary information]. Under the premise of plaintext, each party participates in future recovery through their respective new private key shares; after the transcription update operation is written to the ciphertext object... , and target public key All remain unchanged, thus maintaining the public verifier's traceability of historical versions of the encrypted object.

[0067] The public-key encryption component that supports replayable open verification is: Primitives, including at least key generation algorithms Explicit randomness encryption algorithm Decryption algorithm Opening algorithm and open verification algorithm Five algorithms; the open verification algorithm satisfies: for any legitimate key pair and plaintext-randomness pair ,have:

[0068] ;

[0069] And for any non-holding The verifier, given a public witness and ciphertext The verifier can independently recalculate the ciphertext and... The comparison does not require calling the decryption algorithm.

[0070] The distributed key generation protocol in step S2 includes:

[0071] All participating parties Randomly select scalars And calculate ,right Generate a commitment value and broadcast it; each participant then publishes the commitment value to verify commitment consistency and calculate the joint public key:

[0072] ;

[0073] Each participating party The number of times a constant term is constructed does not exceed polynomial ,Will Send to participants via a private authentication channel Each participating party verifies the consistency of the received share based on the Feldman commitment, i.e., checks:

[0074] ;

[0075] After verification, the participating parties Calculate your own private key share and public key share:

[0076] ;

[0077] And further generate knowledge about it. And satisfy The zero-knowledge proof is used to broadcast the public key share and the zero-knowledge proof to other participants.

[0078] Unpredictable session random numbers in step S3 The subset of participants that meet the threshold conditions is jointly generated in the following manner: Each participant Each selects a local random number And broadcast a commitment After all commitments have been collected, all parties will publicly commit to them, and the consistency of the commitments will be verified before calculation:

[0079] ;

[0080] Among them each Sort by participant index in ascending order; no single participant can make a unilateral decision. The value of is guaranteed, and at least one participant must provide a truly random number. The unpredictability.

[0081] And a computer-readable storage medium having a computer program stored thereon.

[0082] Compared with the prior art, the present invention has at least the following beneficial effects.

[0083] End-to-end injection of encrypted object identifiers eliminates the risk of cross-object reuse. This invention uses encrypted object identifiers... By injecting internal random seed derivation, public seed label derivation, temporary key derivation of domain labels, opening binding digests, and challenge string hashes at every computational level, a complete domain isolation chain is formed from coordinated transcription to final witnessing. Even with the same set of participants, the same public message, and the same threshold parameters, different ciphertext objects will inevitably generate different internal random seeds, different temporary keys, and different binding digests, fundamentally eliminating the possibility of obfuscation and reuse across ciphertext objects during coordinated transcription. In contrast, existing schemes do not include ciphertext object identifiers in seed derivation and digest computation, creating a potential attack surface for cross-object reuse.

[0084] The deterministic standby coordination initiator mechanism eliminates single points of failure in the coordination node without introducing new randomness. This invention... Once determined, a complete priority list of backup coordinators is generated using a deterministic permutation function. Each participant can independently compute the same result locally without additional communication. When the primary coordinator goes offline after writing the coordination challenge group element, the backup party directly reuses the same coordination challenge group element already recorded in the public transcription to continue advancing the protocol without regenerating any random input. This ensures that the encryption and recovery phases obtain the same internal random seed based on the exact same aggregation path. Existing schemes in this scenario either force the coordinator to remain online or reinitialize the coordination process, thus compromising the determinism of the recovery path.

[0085] A participant set change adaptation mechanism ensures the long-term recoverability of the ciphertext. This invention utilizes a share redistribution protocol based on the intersection of the old and new participant sets to migrate the valid private key share to the new participant set without recovering the plaintext private key or changing the joint public key. After the extended transcription field is written to the ciphertext object, , and target public key All remain unchanged. The original verification results of the public verifier for historical versions of the ciphertext object are unaffected. At the same time, when the new participant set is restored in the future, it can aggregate the same secret group elements as the original encryption stage, thereby correctly reconstructing the internal random seed and decrypting the dual-track ciphertext. The existing scheme does not have any corresponding handling for dynamic changes in the participant set. The ciphertext will be permanently deactivated after the participant set no longer meets the threshold.

[0086] This invention enables replayable verification, allowing for public third-party auditing without requiring confidential materials. The algorithm utilizes publicly available cryptographic randomness This mechanism enables any verifier to independently recompile the encryption process without needing to possess a share of the private key, an internal random seed, or a private key under escrow, to verify the replayability consistency between the public witness and the ciphertext component. The binding digest is written into the ciphertext transcription before the challenge string is generated, eliminating the possibility of the ciphertext generator selectively forging the witness after learning the challenge. The interleaved witness disclosure mechanism ensures that each index position only discloses one side of the open information, preventing public verifiers from simultaneously obtaining the random value and response value under the same index, thus preventing them from directly calculating the private key difference. These mechanisms together guarantee the compatible coexistence of public verifiability and recovery path confidentiality.

[0087] This invention discloses a lightweight validation rejection path for seed tags during the recovery phase. As a quick verification anchor point for the correctness of the recovery: if the recovery end uses an incorrect set of participants, an incorrect coordinated transcription, or is tampered with. If the wrong secret group elements are aggregated, then the reconstruction is performed. Will be in the ciphertext In case of inconsistency, the system can identify errors and stop before decrypting any ciphertext component, avoiding the output of meaningless decryption results as valid private keys.

[0088] The system parameters are configurable to adapt to different security and storage requirements. The number of verification rounds for this invention is as follows. Threshold parameters Scale of Participants Both the length of the encrypted object identifier and the length of the encrypted object identifier are configurable parameters. Implementers can flexibly balance the two based on actual security needs and storage overhead without affecting the core security attributes of the protocol. Attached Figure Description

[0089] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. Obviously, the drawings described below are merely some embodiments of the present invention, and those skilled in the art can obtain other drawings based on these drawings without creative effort. In the drawings:

[0090] Figure 1 This is a publicly verifiable private key escrow and threshold recovery technology process. Figure 1-2 layer;

[0091] Figure 2 The technical flowchart for a publicly verifiable private key escrow and threshold recovery method is shown in layers 3-6. Detailed Implementation

[0092] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0093] It should be noted that the following detailed descriptions are exemplary and intended to provide further explanation of this application. Unless otherwise specified, 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 pertains.

[0094] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the exemplary embodiments according to this application. As used herein, the singular form is intended to include the plural form as well, unless the context clearly indicates otherwise. Furthermore, it should be understood that when the terms "comprising" and / or "including" are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof.

[0095] Example 1

[0096] This embodiment describes the complete set of common parameters established during the system initialization phase. See also... Figure 1The gray rectangles represent confidential data, the white rectangles represent public data, the thick white rectangles represent the processing steps, the dashed clips represent confidential data streams, and the gray dashed arrows represent cross-track dependencies.

[0097] The initialization phase requires completing the following five tasks in one go: First, selecting the elliptic curve group to carry out all cryptographic operations; second, establishing a family of domain-separated hash functions throughout the entire protocol to prevent cross-reuse of hash outputs between different protocol components; third, constructing key derivation functions that meet the requirements of deterministic replayability; and fourth, planning the namespace for ciphertext object identifiers to ensure that the identifiers generated by different managed sessions are valid. Fifth, it provides a public-key encryption component that supports replayable open verification, ensuring global uniqueness. The complete algorithm definition.

[0098] The above five tasks are indispensable. If the domain separation framework is incomplete, hashing to the group function and ordinary hash functions may share the output space, causing cross-component collisions; if If a namespace lacks global uniqueness guarantees, there is a risk of identifier collisions between different ciphertext objects, making cross-object transcription and reuse attacks possible; if If the open verification algorithm is not fully defined, the public verifier cannot independently verify the legitimacy of the ciphertext without holding the private key.

[0099] Assume the system security parameters are In this embodiment, This corresponds to a 256-bit elliptic curve security level.

[0100] Select the elliptic curve group that satisfies the following conditions The group order is a prime number. ,satisfy Group generator is It has a publicly available canonical encoding; the discrete logarithm problem on a curve is computationally infeasible; the group elements support canonical byte encoding functions. ,and It is a single-shot.

[0101] Specifically, this embodiment uses the secp256k1 curve, whose group order is:

[0102] ;

[0103] Group generator It adopts the base point defined in the secp256k1 specification and uses a compressed encoding format (33 bytes). All scalar operations are performed within... The above are multiplication and addition pairs. Take the mold.

[0104] For situations requiring the output of the canonical encoding of group elements, the following convention applies. Take a 33-byte sequence in compressed format; for infinity, the convention is... .

[0105] To avoid hash collisions between different protocol components, the system adopts a unified domain-separated label mechanism. The global hash function family is defined as follows.

[0106] Let the underlying hash function be - The output length is 256 bits. Define a hash call with field-separated labels as follows:

[0107] ;

[0108] in It uses 4-byte big-endian encoding for the length of the input bytes to prevent different inputs from producing the same byte sequence due to concatenation.

[0109] The system is predefined as shown in Table 1 below:

[0110] Table 1. Tag Set (all are ASCII encoded byte strings):

[0111] ;

[0112] All tags are prefixed with the protocol version number v1 to prevent incompatible output spaces from arising under the same underlying hash function during future version upgrades.

[0113] In addition to the ordinary hash output, the system also needs to hash to the group function: ;

[0114] This embodiment uses the hash_to_curve method defined in RFC9380, with the secp256k1 curve and SHA-256 as the underlying layer, and uses the expand_message_xmd expansion function, with the field delimiter string set to PVAE_v1_hash_to_curve. The output is evenly distributed in Furthermore, the security proof in RFC9380 guarantees that there is no known discrete logarithmic relationship, meaning that for any message... ,calculate It is computationally infeasible.

[0115] Key derivation function Used to deterministically derive temporary private key scalars from an internal random seed, defined as:

[0116] ;

[0117] in , For index The 4-byte big-endian encoding is output in It is evenly distributed on the surface.

[0118] in, The output must be Evenly distributed on top, but - The output space is ,and Directly taking the modulus will introduce approximately The magnitude of the deviation. For For the safety objective, this deviation is negligible; for more stringent uniformity, rejection sampling or expanding the hash output can be used. Modulo operation is performed after bitwise shift. This embodiment uses direct modulo operation and notes that this deviation does not constitute an attack vector in security analysis; Index It must be injected along with the domain tag; if only used... For input, then different indices The call may produce relevant output even when the domain labels are different; this embodiment achieves this by... Embedded Ensure different ciphertext objects The output space is completely isolated.

[0119] Each private key escrow session corresponds to a unique ciphertext object identifier. Its generation method is as follows:

[0120] ;

[0121] in The target public key corresponding to the private key to be managed. A session random number jointly generated by the participants who meet the threshold conditions.

[0122] The global uniqueness is guaranteed by the following two mechanisms:

[0123] First layer: The input contains That is, the hash value of the target public key, ensuring that different target public keys will necessarily produce different hash values. .

[0124] Layer 2: Even if the same target public key is managed multiple times (e.g., ciphertext update or remanagement), due to... Randomness is jointly contributed by participating parties that meet the threshold conditions, and the probability of a collision does not exceed [a certain value]. , and safety parameters match.

[0125] It is worth noting that, It must be determined before the coordinator initiates the distributed random number generation and written into the public coordination transcript as part of the coordination input. This timing constraint ensures A one-way, unbreakable binding is formed with a specific ciphertext object: any attempt to transfer it... Reusable in different All operations will affect the calculations during the recovery phase. With the ciphertext If inconsistent, it will be automatically rejected.

[0126] The complete instantiation of the RO-PKE primitive is as follows: a public-key cryptographic component that supports replayable open verification. It includes the following five algorithms. I. Key Generation : Output key pair .Require If sampled Then resample; the probability of this event is... This can be ignored. II. Explicit Randomness Encryption Enter public key plaintext scalar Encryption randomness ,implement:

[0127] ;

[0128] ;

[0129] ;

[0130] Output ciphertext ,in , III. Decryption Enter your private key ciphertext ,implement:

[0131] ; ;

[0132] Output plaintext Its correctness is determined by... Guarantee. IV. Open. The input to the algorithm is ciphertext. Plain text and cryptographic randomness Directly output witness This emphasizes: The algorithm does not require a private key. Witnessing The randomness must be the one used during actual encryption, not something constructed afterward. V. Open Verification Enter public key ciphertext plain text Encryption randomness Perform the following two checks:

[0133] Step (a): Check the consistency of randomness:

[0134] ;

[0135] Step (b): Check the consistency of the encryption equation:

[0136] ;

[0137] Output only if both checks pass. (Verification passed); otherwise, output (Verification failed).

[0138] The key here lies in step (b) using Instead :because Both are equivalent, but the former only requires knowing... and The latter needs to know Therefore, the public verifier, without possessing the private key, only needs to know the randomness used during encryption. This allows for a complete recalculation of the encryption process and comparison with the ciphertext, enabling replayable opening and verification.

[0139] This instantiation satisfies the following security property: Ciphertext Indistinguishability (IND-CPA): Under the random oracle model, for unknown... The opponent In Indistinguishable from random values, therefore Covered up All information. Replayability and completeness: for any legitimate encryption process. , This is necessarily true. Replayable Binding Robustness: For any fixed ciphertext... and public key There are no two different sets This allows both to pass Verification is required unless the adversary can find the hash function. A collision. Zero knowledge required: public witnessing. Do not disclose Any information; calculations are required during the verification process. However, this only requires disclosing the parameters and ,right There was no leak.

[0140] To ensure that each hash call is independent in subsequent embodiments, this embodiment publishes a complete list of all session domain separator tags during the initialization phase, so that participants, public verifiers, and authorized recovery terminals can independently confirm locally that the tags they call are consistent with the global definition.

[0141] Tag collection Defined as the set of twelve tag strings listed in Table 1 of this embodiment, and published as part of the public parameters in the following manner:

[0142] ;

[0143] After initialization, system common parameters Defined as:

[0144] ;

[0145] in For the commitment algorithm, this embodiment takes , It satisfies both binding and concealment.

[0146] All participants, public verifiers, and authorized recovery terminals hold [the necessary documents / equipment]. The same copy. There is no need for confidentiality; any party can independently verify the legitimacy of each component.

[0147] It should be noted that all group elements must first undergo [a certain process] before being written into the hash input. Convert to a canonical byte sequence. If the intermediate results of group operations (such as affine coordinate pairs) are directly converted... Writing a non-canonical representation of coordinates into a hash may lead to inconsistent hash values ​​due to differences in coordinate representation across implementations, thus breaking cross-implementation interoperability. The output should be checked before taking the modulus to see if it is true. If it is Then the index Replace with Re-deriving (to prevent encryption failure due to the temporary private key being zero), this mechanism has a probability of occurring. This does not affect the correctness of the agreement. Cryptographic randomness It must be done independently from each encryption. Uniform sampling is required, and samples must not be reused. In practical implementations, a cryptographically-level random number generator provided by the operating system can be used, and the sampling process should be checked after sampling. .

[0148] Example 2

[0149] This embodiment establishes the system common parameters based on Embodiment 1. Based on this, the entire process from distributed key generation to complete ciphertext output via private key escrow is described. Assume the system has a total of... Each participating party The threshold value is ,satisfy Recovering the private key requires no less than The collaboration involves multiple parties. The key owner is denoted as Alice, who holds the private key to be held in escrow. Corresponding target public key The number of public verification rounds is set to... ,satisfy To ensure that the reliability error of non-interactive proof does not exceed .

[0150] This embodiment adopts the following encoding rules: group elements Standard coding Compressed to 33 bytes in SEC1 format; scalar in Standard coding 32-byte big-endian format; non-negative integer index encoding It is in 4-byte big-endian format. All hash calls use the field-separated format defined in Example 1. Specific labels from Used from within. The distributed key generation protocol is comprised of all... The process is executed jointly by all participating parties, and each party outputs its share of the private key. Public key shares and joint public key .

[0151] The first phase involves commitment and joint public key negotiation among participating parties. Perform the following steps independently: ;

[0152] ;

[0153] Commitment value Broadcast to all other participants. Waiting for all... After all commitment values ​​have been collected, each participating party broadcasts its commitment value in sequence. .

[0154] Each participating party has a responsibility to each verify: ;

[0155] If any verification fails, the protocol is terminated and marked. This is considered a malicious party. After all verifications are successful, each participating party calculates the joint public key: ;

[0156] The second phase involves share distribution and the sharing of Feldman verifiable secrets; all participating parties by The number of times to construct the constant term is exactly polynomials:

[0157] ;

[0158] Where the coefficient , .

[0159] Calculate and broadcast the Feldman commitment vector:

[0160] ;

[0161] The agreement Therefore This is consistent with the first phase.

[0162] Through a private authentication channel Send separately ( , ); Self-retention .

[0163] All participating parties Received from share Then, perform Feldman consistency verification:

[0164] ;

[0165] The above formula utilizes polynomials in The evaluation at the specified point has a linear relationship with the commitment vector. If the verification fails, Broadcast to The complaint is rejected; if the complaint is true (and other participants verify the facts), the party is removed from the set of participants. After all valid shares have been verified, Calculate your own private key share and public key share: ;

[0166] The third phase involves zero-knowledge proofs of public key shares; all participating parties Generate about satisfy Schnorr proofs of knowledge to prevent rogue public-key attacks:

[0167] ;

[0168] ;

[0169] ;

[0170] Broadcast to all other participants ,in .

[0171] Verification party checks: ;

[0172] as well as ;

[0173] Simultaneously check: ;

[0174] That is, the sum of the public key shares of each party equals the joint public key, to confirm the global consistency of the share aggregation. After all verifications pass, the distributed key generation is complete.

[0175] Before the private key escrow phase begins, Alice determines the subset of participants for this escrow session. ,satisfy . The participating parties jointly generate unpredictable session random numbers. .

[0176] All participating parties ( Independent execution:

[0177] ;

[0178] ;

[0179] broadcast .treat After all commitment values ​​from all participating parties have been collected, each party will broadcast its commitment value in turn. And mutually verify the consistency of commitments.

[0180] After all verifications pass, the participants are sorted in ascending order by their index, and the session random numbers are aggregated.

[0181] ;

[0182] in for An orderly arrangement.

[0183] Then, a ciphertext object identifier for this managed session is generated:

[0184] ;

[0185] Once confirmed, it cannot be changed for the entire lifecycle of this managed session. All participants save locally And use it as the unique session identifier in all subsequent protocol steps.

[0186] exist Once determined, each participating party independently calculates its own priority list of coordinating initiators locally. (Sorted in ascending order by index), define the round. Priority sorting seed:

[0187] ;

[0188] Will The former Each byte is interpreted as a replacement index, generated using the Fisher-Yates algorithm. A deterministic random permutation yields a list of alternative coordinators:

[0189] ;

[0190] in For the reason A definite permutation. The main coordinating initiator, ( ) is the first The initiator of the next priority coordination.

[0191] because Only depend With round counters, all participants can independently calculate the same result locally without additional communication.

[0192] Alice will post public information Broadcast to All participants. Each party calculates the message hash:

[0193] ;

[0194] Main coordinating party Using one's own private key share Calculate the elements of the coordination challenge group:

[0195] ;

[0196] in This is the hash-to-group function defined in Example 1. Subsequently The correctness of the DLEQ non-interactive zero-knowledge proof is generated to prove the existence of [the proof]. Make and Established simultaneously:

[0197] ;

[0198] ;

[0199] ;

[0200] ;

[0201] Proof is Verification party checks:

[0202] ;

[0203] ;

[0204] ;

[0205] Write the following into a public coordinated transcription. And broadcast:

[0206] ;

[0207] in To coordinate the initiator index, For the group of participants.

[0208] If the main coordinating party initiates In writing Previously offline (i.e.) If the counter is empty, then all participants will increment the round counter by one. Recalculate:

[0209] ;

[0210] activation As the new initiator of the coordination, it is re-executed, generating a new... And new .

[0211] If the main coordinating party initiates In writing After that (i.e.) and (Already written into public transcription) but offline before the agreement is completed, then the backup coordinating initiator Instead of generating new coordination challenge group elements, they are directly reused. Recorded in Continue to advance the subsequent steps. exist Additional backup activation records:

[0212] ;

[0213] Other participants ( Verification only. The existing ones Proof (this verification is independent of who the current initiator of the coordination is) is that no re-verification is required. The generator's identity. This ensures that replacing the coordinator does not introduce any new randomness input, thus not changing the subsequent aggregation results. The value of , thereby ensuring the internal random seed The recovery path is completely determined.

[0214] Once confirmed, All participating parties except the initiator ( )verify After passing, calculate the threshold response:

[0215] ;

[0216] right Generate DLEQ proof Prove existence Make and Established at the same time, Replace with That's all.

[0217] Through a private authentication channel Send to Alice.

[0218] Alice collected no less than One valid Then (each one was verified to have passed the DLEQ proof), and exactly one of them was selected. A set of indexes of valid responses , Calculate the Lagrange interpolation coefficients:

[0219] ;

[0220] Aggregate to obtain secret group elements: ;

[0221] Correctness verification: satisfy ;

[0222] in The joint private key implicit in the distributed key generation (never known to any single participant).

[0223] Alice checks (At infinity); if it equals the point at infinity, the agreement is abnormally terminated (the probability of this event is negligible under the condition of honest participants).

[0224] ;

[0225] ;

[0226] and Alice stores it locally and does not write it into any public material. and This will be written into the final publicly verifiable ciphertext.

[0227] Alice uses and Federation-driven, for each validation index Derive two sets of temporary key pairs:

[0228] First-track temporary key: ; ;

[0229] Second-track temporary key: ; ;

[0230] If any (probability is) (can be ignored), then with Replace the index and re-forge. All Once the ciphertext is constructed and the challenge string is generated, the temporary private key is securely erased by Alice and is no longer retained.

[0231] Alice for each index Perform the following steps independently:

[0232] Track 1: ; ; ;

[0233] Track 2: ; ; ;

[0234] It is important to note that: and Each sample must be taken independently under each index and cannot be reused across indexes. First-track encryption. (Purely random masking value), second-track encryption (Response value containing private key information); neither of these will be disclosed individually. Only through joint efforts can it be determined .

[0235] Alice in all , , , Once determined, for each index The binding summary is calculated separately for each of the two sides of the open information:

[0236] ;

[0237] ;

[0238] The purpose of the binding digest is to form a prior commitment to the opened information: Alice will open the information without knowing the challenge string. and The ciphertext is written into the transcription, so even if Alice knows every bit of the challenge string, she cannot replace the open information without modifying the ciphertext at the same time, thus eliminating the possibility that Alice selectively forges witnesses for the challenge string.

[0239] Pay attention here. A digest hash is injected, which ensures that the open digest formats are incompatible under different ciphertext objects, preventing digest reuse across objects.

[0240] Alice on coordinated transcription The entire sequence is normalized to obtain Then the challenge string is calculated:

[0241] ;

[0242] in Take the first part of the hash output The bits, interpreted in most significant bit-first (MSBfirst) order, are the... The position is denoted as , .

[0243] For each index According to the challenge sequence number Bit selection public side: If Public First Track Witness Confidential ;like Public Second Track Witness Confidential .

[0244] Each index exposes only one side. In the case of a round, if the opponent does not know However, attempting to forge all witnesses requires guessing an average of 128 independent bits correctly, with a success rate of [missing value]. .

[0245] After the above process is completed, the final output is publicly verifiable ciphertext. Defined as a data structure containing the following fields:

[0246] ;

[0247] in Canonical serialization Defined as:

[0248] ;

[0249] If the backup coordinator is activated. Additional activation records:

[0250] ;

[0251] All fields in this database are public information and can be securely hosted on public media such as cloud storage or blockchain. Alice completes... After the construction, ,each , , , All temporary private keys and Safely erase from memory, retain only (The private key to be held in custody) will be used for subsequent business operations, or... It also erases and relies on future thresholds for recovery.

[0252] Example 3

[0253] This embodiment, based on Embodiments 1 and 2, describes the complete execution process of three independent stages: the public verification stage is performed by any holder of publicly verifiable ciphertext. The verification process is performed independently; the threshold recovery phase is jointly conducted by the authorized recovery unit and no less than [number missing] [units missing]. The process is completed collaboratively by all participating parties; the participant set change adaptation phase is triggered when a participant leaves or joins, ensuring that the already managed encrypted data can still be correctly restored by the new participant set after the set change.

[0254] The verifier, authorized recovery terminal, and participating parties all possess the system's public parameters. And the publicly verifiable ciphertext generated by Example 2:

[0255] ;

[0256] Public verification by holder Executed by any party, requiring no secret materials, output and receive ( ) or refuse ( ).

[0257] The verifier first performs a format check: Confirmation , ;confirm and ;confirm , Confirm coordinated transcription Includes fields ,and ;confirm , For all Established; confirmed The format is valid, and the group element belongs to... scalar belongs If any format check fails, immediately output "Reject".

[0258] Verification party from The elements of the coordination challenge group were analyzed. Coordinating the public key share of the initiator Public information ,calculate:

[0259] ;

[0260] Subsequent verification DLEQ ​​proof in :

[0261] ;

[0262] ;

[0263] ;

[0264] examine If not, then refuse. If a backup coordinator activation record exists, the validity of the activation record is verified in the same way, but there is no need to verify the backup party's new DLEQ proof (because...). (Unchanged).

[0265] Verifier based on Recalculate the challenge string in the public fields; check If the response is not equal, the transcription is immediately rejected. This step ensures the integrity of the encrypted transcription: if... , , any , or If it is tampered with, then recalculate. Inevitably and different.

[0266] For each satisfied index ,from Analysis of the first track witness Perform the following three checks in sequence:

[0267] Check the group relationship of random values: ;

[0268] Check open digest consistency: ;

[0269] Check for consistency of replayable opening:

[0270] ;

[0271] Expand Two-step calculation:

[0272] ;

[0273] ;

[0274] ;

[0275] If all three checks pass, the index verification is successful; if any one fails, a rejection is output.

[0276] For each satisfied index ,from Analysis of the second track witness Perform three checks in sequence: Check the relationship between response value groups: ;

[0277] This equation is equivalent to verifying ,Right now However, the verifier does not need to know. or This check can be completed because It has already been given in the publicly available encrypted text;

[0278] Check for consistency of the second open digest:

[0279] ;

[0280] Check the consistency of the three-way replayable opening: ;

[0281] Expand the calculation: ;

[0282] ;

[0283] ;

[0284] If and only if DLEQ verification, challenge string consistency check, and all When each item-by-item verification at each index position passes, the public verifier outputs... (Accept); otherwise output (Rejection) and can further locate the first failed index to assist in diagnosis.

[0285] Threshold recovery is led by the authorized recovery terminal and must be coordinated by no fewer than [number missing] parties. The process involves collaboration among all participating parties, and public verification is a necessary prerequisite.

[0286] The authorized recovery end first performs the following: Perform the complete public verification process. If the public verification output... If the output is invalid, the recovery process will be immediately aborted and an invalid ciphertext report will be issued; if the output is invalid... If so, proceed to the next steps. These preliminary steps ensure that the recovery end does not waste the computing power of the threshold participants on invalid ciphertext.

[0287] Authorized recovery terminal from The following fields are parsed: ;

[0288] From the set of participants The subset determined in this recovery ,satisfy .Towards The participating parties in China broadcast a request to resume broadcasting, along with... , And the session identifier for this recovery.

[0289] All participating parties Upon receiving the request, verify the received data. With its local archive In If consistent, then calculate the threshold response using your own private key share:

[0290] ;

[0291] right Generate DLEQ proof Prove existence Make and Established simultaneously:

[0292] ;

[0293] ;

[0294] ;

[0295] ;

[0296] Through a private authentication channel Send to the authorized recovery end.

[0297] The authorized recovery end receives each Verify the DLEQ proof. Let the set of verified responses be denoted as... ,like Then the recovery will be suspended.

[0298] from Select exactly A subset of indexes of valid responses Calculate the Lagrange coefficients:

[0299] ;

[0300] Aggregate and restore secret group elements: ;

[0301] Compute the reconstruction seed and seed label:

[0302] ;

[0303] ;

[0304] Perform seed tag consistency check:

[0305] ;

[0306] If they are not equal, it indicates that the aggregation result is incorrect. Compared with the original encryption stage The difference could be due to the participants providing incorrect responses or using incorrect methods. ,or The data has been tampered with. At this point, the authorized recovery end suspends the recovery process and can identify malicious actors by isolating responses one by one.

[0307] If they are equal, then , The internal random seed has been correctly reconstructed.

[0308] Authorized recovery terminal use and Re-derive all A temporary private key:

[0309] ;

[0310] ;

[0311] For each index Decrypting the dual-track ciphertext:

[0312] ;

[0313] ;

[0314] For each index Calculate candidate values ​​for the private key: For each Verify the consistency between the candidate value and the target public key: ;

[0315] If all All candidate values ​​satisfy Then output the recovery private key: ;

[0316] If any Make If the condition is met, then the output will be rejected, and the corresponding index will be set. Marked as an anomaly location. An anomaly typically indicates the corresponding... or If damage occurs during storage and transmission, or if the corresponding temporary key derivation is abnormal, the authorized recovery end can utilize public witness. Further diagnosis: If and (from (Read from the middle), then confirm. Damaged; if and Then confirm damage.

[0317] After the recovery is complete, the authorized recovery terminal will ,all , , and Safely erase from memory.

[0318] When a participant leaves the original participant set, hardware fails, or a new participant joins, the coordinated transcription of the already managed ciphertext will occur. The corresponding set of participants may not meet the liveness requirements for threshold recovery. This embodiment is described without modification. , and Under the premise of [missing information], an adaptation method is used to maintain the long-term recoverability of ciphertext by expanding transcription fields.

[0319] Let the old set of participants be The old threshold value is The new participants are grouped as The new threshold value is Define intersection:

[0320] ;

[0321] The necessary prerequisite for adaptation is This means that there are still enough old participants holding a valid share of private keys in the intersection, enabling the joint private key to be rebuilt. The share redistribution is completed under the premise of plaintext. If this condition is not met, threshold restoration must be performed first. Then, restart the entire hosting process.

[0322] All participating parties With its current share of private key For a constant term, the number of constructions is... The redistribution polynomial:

[0323] ;

[0324] in , .

[0325] Broadcast Feldman redistribution commitment vector:

[0326] ;

[0327] The agreement Therefore (Consistent with the original public key share, which can be directly verified from the old DKG output).

[0328] Sub-shares will be redistributed via a verified private channel. Send to new participants ( ).

[0329] New participants Received from After the redistribution of sub-shares by all parties, for each verify:

[0330] ;

[0331] After verification, Calculate your new private key share: ;

[0332] Wherein the Lagrange coefficient: ;

[0333] Calculate the new public key share: ;

[0334] Verifiable yes The correct share under the new polynomial, that is, satisfying: ;

[0335] For any size subset of This property guarantees that the new set of participants can be aggregated into identical groups through Lagrange interpolation during the recovery phase. .

[0336] Further generate information about Schnorr knowledge proof and broadcast :

[0337] ;

[0338] ;

[0339] ;

[0340] After all new participants' shares have been verified, the change and adaptation information will be written. Extended transcription field :

[0341] ;

[0342] in A timestamp or sequence number for the change operation, used to distinguish multiple set changes on the same ciphertext object. The complete data object after the ciphertext update is defined as follows:

[0343] ;

[0344] Notice In , , Original Challenge String The original dual-track ciphertext remains unchanged, and the public verifier verifies it. When performing public verification, compared with the original The results were exactly the same.

[0345] Hold at will A third party can Perform the following verification independently:

[0346] Verification 1: Check Confirm that the extended transcription is bound to the correct ciphertext object;

[0347] Verification 2: For each ,examine ,in By checking the old DKG output, it is confirmed that the constant term commitment of the redistribution polynomial is consistent with the old public key share: ;

[0348] Verification 3: For each new participant Verify Schnorr knowledge proof :

[0349] ;

[0350] Verification 4: Check the global consistency of the public key share of the new participant, i.e., for any size... test subset Calculate Lagrange combinations: ;

[0351] This equation holds at points on the elliptic curve, meaning the public verifier can verify the data without knowing any private key shares, because... It is a globally public federated public key;

[0352] Verification 5: For each Feldman commitment vector Verify any known new share In line with commitments: ;

[0353] If all five verifications above are passed, the publicly verified party confirms... The extended transcription write is valid; it does not alter the ciphertext object.

[0354] After the participant set is changed, the authorized recovery terminal will use it when initiating recovery in the future. In Rather than original Determine the current set of valid participants and select... , New participants With its new private key share calculate: ;

[0355] The authorized recovery end receives all Verify the DLEQ proof and perform Lagrange interpolation based on the new index set:

[0356] ;

[0357] in , Due to share redistribution, The above aggregation result remains unchanged, and is consistent with the result of the original encryption stage. Same, therefore The recovery process continues normally, outputting the exact same private key as the one used to recover using the old set of participants. .

Claims

1. A publicly verifiable method for private key escrow and threshold recovery, characterized in that, Includes the following steps: S1. Initialize system common parameters, the system common parameters including at least those of order [order missing]. Elliptic curve group, group generator Hash function Key derivation function Hash to group function Commitment algorithms and public-key cryptographic components that support replayable open verification. Simultaneously, it generates a global ciphertext object identifier namespace and a session domain delimiter tag set; S2. The participating parties execute a distributed key generation protocol to generate private key shares for each participant. Public key shares and joint public key ; S3. During the private key escrow phase, a threshold value of not less than [a certain threshold value] is required. The participating parties execute a distributed random number generation protocol with session locking to generate unique ciphertext object identifiers. Internal random seed Public seed tags and public coordinated transcription ; wherein, the The coordinated transcription process is determined and written into the coordinated input by the participating parties before the generation of coordinated transcription, so as to enable coordinated transcription. It forms an unbreakable one-way binding with the unique ciphertext object; S4. The key owner relies solely on the internal random seed. and the ciphertext object identifier Commonly driving key derivation, for each index Derive two temporary key pairs, and for the private key to be managed. Construct a two-track ciphertext, where the first track encrypts a random value. Second-track encrypted response value ; S5. The key owner generates a binding digest for the potential open information on both sides of each index position, and generates a challenge string based on the ciphertext transcription containing the target public key, public seed tag, ciphertext object identifier, public coordination transcription, dual-track ciphertext and binding digest; and forms a publicly verifiable ciphertext by publicly revealing only one side of the witness at each index position based on the challenge string. S6. The public verifier recalculates the challenge string based on the publicly verifiable ciphertext and checks the open digest, group relation, and ciphertext replayability consistency of the public side according to the challenge string; during the recovery phase, the authorized recovery end parses the ciphertext object identifier from the ciphertext. And it is injected as a domain separation parameter into the coordinated transcriptional reuse process, with a threshold value of not less than [value missing]. The participants in the same Under constraints, the same internal random seed is regenerated. After verifying that the regenerated public seed label is consistent with the public seed label in the ciphertext, the dual-track ciphertext is decrypted and the private key to be managed is recovered.

2. The publicly verifiable private key escrow and threshold recovery method according to claim 1, characterized in that, Ciphertext object identifier in step S3 Generated in the following way: ； in The target public key corresponding to the private key to be managed. For this managed session, there are no fewer than An unpredictable session random number jointly generated by several participating parties, the session random number in Once confirmed, it cannot be changed; the stated Before being transmitted to the coordinating initiator, the transcription is jointly witnessed by a subset of participating parties that meet the threshold conditions and is publicly coordinated. Explicit records; The distributed random number generation protocol with session locking in step S3 includes: The coordinating initiator is selected from the subset of participants that meet the threshold conditions according to publicly known deterministic rules. If the coordinator goes offline after the start of coordination but before the completion of the coordinated transcription, the next participant in the backup coordinator sequence is activated sequentially according to the deterministic rules. The backup coordinator directly reuses the coordination challenge group elements already written into the public transcription. And its proof continues to advance the agreement without the need for regeneration. Other participants do not need to be re-verified. The identity of the generator is verified only. A consistency proof is satisfied for the corresponding public key share; this ensures that replacing the coordinator does not introduce new randomness input, thus not changing the internal random seed. A deterministic recovery path; The deterministic rule generates an ordered alternative list from the participant set based on the following sorting function: ； in The set of participant indices that meet the threshold conditions. This is the counter for the current round; the output of the sorting function is a pseudo-random permutation, allowing all participants to locally compute the complete backup sequence before the protocol begins, and the backup sequence is consistent with... Strongly bound, spare sequences across ciphertext objects cannot be reused; Internal random seed in step S3 and public seed tags Generate in the following way: ； ； in The secret group elements are obtained by aggregating Lagrange interpolation among the participants who meet the threshold conditions. Standardize its coding. Injected as a domain separator parameter into the derived function and Not written into public encrypted text, and All of these are written into publicly encrypted text.

3. The publicly verifiable private key escrow and threshold recovery method according to claim 1, characterized in that, The temporary key derivation method in step S4, driven by both the internal random seed and the ciphertext object identifier, is as follows: ； ； Among them, the domain label and Each contains a ciphertext object identifier as context, which is used to derive different temporary keys from the same internal random seed under different ciphertext objects; The dual-track ciphertext in step S4 includes: for each index Randomly select random values And the first encryption randomness ,calculate: ; Calculate response value Randomly select the second encryption randomness ,calculate: .

4. The publicly verifiable private key escrow and threshold recovery method according to claim 1, characterized in that, The binding summary in step S5 includes: ； ； The binding digest injects a ciphertext object identifier into the domain separator label. This is used to ensure that open digests under different ciphertext objects cannot be reused across objects; the binding digest is written into the ciphertext transcription before the challenge string is generated.

5. The publicly verifiable private key escrow and threshold recovery method according to claim 1, characterized in that, Challenge string in step S5 Generated from the following transcription hash: ； in Indicates the first step of extracting the hash output. 1 bit; the challenge string will simultaneously The hash input is incorporated to ensure an inseparable binding between the generation of the challenge string and the unique identifier of the ciphertext object; when the challenge string... Bit At that time, the first The first track witness at each index position ;when At that time, the first The second track witness at each index position Only one side of the witness is exposed for each index position.

6. The publicly verifiable private key escrow and threshold recovery method according to claim 1, characterized in that, During the recovery phase, the authorized recovery client performs the following steps: First, perform a full public verification; after successful verification, parse the encrypted text. and coordinated transcription It is required to be no less than the threshold value. The participants in the domain parameters Constrained reuse The same coordination challenge group elements recorded in the middle Each participant calculates the threshold response. And it is transmitted through a certified private channel; Authorized recovery end aggregation obtained ,calculate: ； ； like With the ciphertext If they don't match, reject; if they match, use. and Derive all temporary private keys again and decrypt them separately. and get and ,calculate If all If they match, output the common value as the recovery private key; otherwise, reject the request.

7. The publicly verifiable private key escrow and threshold recovery method according to claim 1, characterized in that, The method also includes a participant set change adaptation step: when the participant set changes from Change to a new set At that time, a private key share redistribution protocol is executed to ensure that the new set of participants holds the same joint public key. The new private key share is used to coordinate the transcription of already escrowed ciphertext objects. Perform the transcription update operation: The transcription update proof is generated from the intersection subset that simultaneously satisfies the threshold conditions of the old participant set and the new participant set. The public key information of the new participant set and the new threshold parameters are appended to the extended transcription field of the ciphertext object, so that the ciphertext that has been held can still be recovered by the new participant set after the participant set changes, and the authenticity of the extended transcription field can be independently verified by the public verifier. The transcriptional update operation includes the following sub-steps: Select participants from those that belong to both the old participant set and the new participant set, with a minimum of the old threshold value. Several participants, based on their old private key shares. Re-aggregate to obtain secret group elements It also provides privately verified shares to participants in the new participant set who do not hold old shares, enabling all participants in the new participant set to access shares without obtaining [the necessary information]. Under the premise of plaintext, each party participates in future recovery through their respective new private key shares; after the transcription update operation is written to the ciphertext object... , and target public key None of them change.

8. The publicly verifiable private key escrow and threshold recovery method according to claim 1, characterized in that, The public-key encryption component that supports replayable open verification is: Primitives, including at least key generation algorithms Explicit randomness encryption algorithm Decryption algorithm Opening algorithm and open verification algorithm Five algorithms; the open verification algorithm satisfies: for any legitimate key pair and plaintext-randomness pair ,have: ； And for any non-holding The verifier, given a public witness and ciphertext The verifier independently recalculates the ciphertext and compares it with... Compare.

9. The publicly verifiable private key escrow and threshold recovery method according to claim 1, characterized in that, The distributed key generation protocol in step S2 includes: All participating parties Randomly select scalars And calculate ,right Generate a commitment value and broadcast it; each participant then publishes the commitment value to verify commitment consistency and calculate the joint public key: ； Each participating party The number of times a constant term is constructed does not exceed polynomial ,Will Send to participants via a private authentication channel Each participating party verifies the consistency of the received shares based on the Feldman commitment, i.e., checks: ； After verification, the participating parties Calculate your own private key share and public key share: ； And further generate knowledge about it. And satisfy The zero-knowledge proof is used to broadcast the public key share and the zero-knowledge proof to other participants.

10. The publicly verifiable private key escrow and threshold recovery method according to claim 1, characterized in that, Unpredictable session random numbers in step S3 The subset of participants that meet the threshold conditions is jointly generated in the following manner: Each participant Each selects a local random number And broadcast a commitment After all commitments have been collected, all parties will publicly commit to them, and the consistency of the commitments will be verified before calculation: ； Among them each Sort by participant index in ascending order; no single participant can make a unilateral decision. The value of , and at least one participant provides a truly random number to guarantee . The unpredictability.

Images