A privacy-enhanced fully dynamic traceable group encryption method and system

Abstract

The technical scheme belongs to the field of encryption technology, and discloses a privacy-enhanced fully dynamic traceable group encryption method.The technical scheme coordinates the receiver anonymity and traceability in the statistical sense while realizing the full dynamic nature of group encryption.A privacy-enhanced fully dynamic traceable group encryption is proposed, and its syntax and security requirements are formally given.As a key component, the technical scheme designs an anonymous label system with controlled traceability and declaration, and gives the formal definition and specific construction.Based on this component, the technical scheme proposes a general privacy-enhanced fully dynamic traceable group encryption construction and proves its security.Further, the technical scheme gives a pairing-based instantiation scheme which combines standard cryptographic components including selective labels, CCA2-secure R NEQ‑ lossy public key encryption scheme, and performance analysis is provided to show its feasibility.

Description

Technical Field

[0001] This technical solution belongs to the field of encryption technology, and in particular relates to a privacy-enhanced, fully dynamic, traceable group encryption method and system. Background Technology

[0002] With the widespread adoption of internet access and the extensive deployment of cloud services, email remains one of the most important digital communication channels globally, widely used by government agencies, businesses, and individuals for information exchange. Statistics and forecasts indicate that by 2024, over 361 billion emails will be sent and received daily worldwide, with approximately 4.4 billion users. Emails often carry highly sensitive information such as political opinions, business agreements, and personal schedules; however, the increasing number of cyberattacks targeting email infrastructure and large-scale data breaches is prompting various entities to accelerate the deployment of encrypted email protection solutions.

[0003] End-to-end email encryption (E2EE) typically relies on mechanisms such as OpenPGP and S / MIME to restrict plaintext access to the sender and receiver to ensure confidentiality. However, since only endpoints are visible to the plaintext, it is difficult for the operations team to execute filtering and admission processes that depend on the content of the email body and attachments. To strike a balance between privacy and functionality, existing research has attempted to use homomorphic encryption and function encryption to run tasks such as spam classification on ciphertext, but these are generally limited by high computational overhead, latency, and restrictions on policy expressiveness and scalability. In contrast, recent work has re-examined group encryption (GE), shifting the focus to admission control and verifiable policy checks for encrypted emails: while maintaining end-to-end confidentiality, gateways / firewalls can verify that the ciphertext is indeed sent to certified organization members and enforce the compliance of preset policy requirements before delivery.

[0004] However, in actual organizational deployments, even with GE's access control and policy checks, the system still needs to be able to identify the intended recipient of specific encrypted messages to support scenarios such as abuse handling, internal investigations, emergency evidence collection, and account hijacking responses, all under compliance authorization and security operation requirements. In traditional GE, "opening" often leads to opening a large number of unrelated encrypted messages in order to track a particular member, thereby exposing the identity of honest users and weakening privacy protection. To address this, Traceable Group Encryption (TGE) introduces a tracking mechanism on top of GE, allowing authorized parties to track the encrypted messages of specific suspicious members while maintaining the anonymity of other members, and supporting "claim / deny" to achieve recipient confirmation and non-recipient denial proof. However, existing TGE still struggles to meet the needs of highly privacy-sensitive, large-scale organizational email systems. For example, in large enterprise internal systems, employees temporarily participating in confidential projects may need stronger anonymity for their identity and email activities; upon returning to their regular positions, traceability should be restored for governance and accountability. Simultaneously, as enterprises continuously add employees and cancel accounts of departing employees, the system must support dynamic addition and removal of members without compromising existing security and anonymity guarantees. To the best of our knowledge, no TGE architecture supports fully dynamic joining and revocation, nor can any GE / TGE framework simultaneously achieve statistical recipient anonymity and traceability within the same scheme. This leads to the core question: how to design a fully dynamic group encryption scheme that uniformly achieves these two seemingly conflicting properties of statistical anonymity and traceability within the same framework?

[0005] Based on the above analysis, the problems and shortcomings of the existing technology are as follows:

[0006] Existing TGE solutions lack support for dynamic user addition and removal, making them unsuitable for scenarios with frequent changes in organizational members. Furthermore, they cannot balance statistical anonymity and traceability of recipients within the same system, making it difficult to simultaneously satisfy privacy protection and compliance accountability, thus limiting their application in practically deployable encrypted email systems.

[0007] The difficulty in solving the above problems and defects lies in the need to simultaneously implement a dynamic revocation mechanism for users within the same traceable group encryption scheme, while taking into account the seemingly conflicting properties of recipient anonymity and recipient traceability in a statistical sense without compromising system availability and security.

[0008] The significance of addressing the above issues and shortcomings is as follows: By designing a privacy-enhanced, fully dynamic, and traceable group encryption solution, it maintains end-to-end encryption of email content while implementing access control and verifiable policy checks at the gateway level. Furthermore, under legal and compliant conditions and with appropriate authorization, it identifies the intended recipient of specific encrypted messages, supporting responses to misuse, internal investigations, emergency evidence collection, and account hijacking incidents, as well as the accountability requirements for compliance audits. Simultaneously, the solution natively supports dynamic scenarios such as member additions, removals, and permission changes, ensuring that the encrypted email infrastructure can evolve stably with changes in organizational size. This allows for a balance between strong privacy and governability in large-scale, highly sensitive email systems, improving overall security and feasibility for implementation. Summary of the Invention

[0009] To address the problems existing in the prior art, this technical solution provides a privacy-enhanced, fully dynamic, traceable group encryption method.

[0010] This technical solution is implemented as follows: a privacy-enhanced, fully dynamic, traceable group encryption method, comprising:

[0011] Step 1: Establish an Anonymous Tag System with Controlled Traceability and Claimability (ATCTC).

[0012] Step 2: System initialization, simultaneously calling ATCTC to generate public parameters and keys for the group manager (GroupManager, "GM") and the opener (OpenAuthority, "OA"), and initializing group information and the public registry.

[0013] Step 3: When a new user joins, an interaction protocol is executed with the GM, and the ATCTC is called to verify the user's membership and issue a group member certificate.

[0014] Step 4: When a member is removed or the member set changes, GM generates and publishes new group information, enabling the system to support dynamic member removal without resetting global parameters.

[0015] Step 5: During encryption, the sender inputs public parameters, GM public key, OA public key, group receiver public key, group information, plaintext message, tag, witness, and predicate, and calls the ATCTC system to generate ciphertext.

[0016] Step 6: The sender generates a proof to demonstrate that the ciphertext format is correct, it was generated for a currently active group member, its intended recipient can recover the message, and the message satisfies certain public policies. The verifier checks the proof; if valid, it outputs 1; otherwise, it outputs 0.

[0017] Step 7: During decryption, the group receiver inputs the private key, public parameters, ciphertext, and tag. If the ciphertext is indeed what they expected to receive, the plaintext is restored; otherwise, a failure symbol is output.

[0018] Step 8: When tracing encrypted text, the opener can perform an open operation on a certain encrypted text. If the encrypted text supports tracing, the active user identity corresponding to the encrypted text will be output. If tracing the encrypted text of a certain group of users, the opener can obtain the tracking credentials of the group of users, call ATCTC, verify any encrypted text, and determine whether the encrypted text was indeed sent to the user.

[0019] Step 9: With their own key, users can call ATCTC to generate publicly verifiable evidence for a given anonymous ciphertext, which convincingly proves whether the ciphertext was indeed sent to them as a legitimate ciphertext; any third party can independently verify this evidence after obtaining it.

[0020] Another objective of this technical solution is to provide a privacy-enhanced fully dynamic traceable group encryption system that applies the aforementioned privacy-enhanced fully dynamic traceable group encryption method, wherein the privacy-enhanced fully dynamic traceable group encryption system includes:

[0021] The ATCTC system module is used to build the ATCTC system.

[0022] The system setup module is used to generate public parameters and keys for GM and OA, and to initialize group information and the public registry.

[0023] The user addition module is used to introduce new group members;

[0024] The user undo module is used to undo group memberships;

[0025] The encryption module is used to encrypt messages and generate ciphertext.

[0026] The proof module proves that the ciphertext format is correct, that it was generated for a currently active group member, that its intended recipient can recover the message, and that the message satisfies certain public policies.

[0027] The decryption module is used to decrypt ciphertext and output plaintext or error symbols. ;

[0028] The tracking module is used to track ciphertext. If the ciphertext supports tracking, the identity of the recipient can be obtained; otherwise, the ciphertext remains anonymous.

[0029] The declaration module is used to generate a publicly verifiable piece of evidence for an anonymous ciphertext, which convincingly proves that the ciphertext was indeed sent to oneself as a legitimate ciphertext.

[0030] Another objective of this technical solution is to provide a computer device, the computer device including a memory and a processor, the memory storing a computer program, the computer program being executed by the processor causing the processor to perform the steps of the privacy-enhanced fully dynamic traceable group encryption method.

[0031] Another objective of this technical solution is to provide a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform the steps of the privacy-enhanced, fully dynamic, traceable group encryption method.

[0032] Another objective of this technical solution is to provide an information data processing terminal, which is used to implement the privacy-enhanced, fully dynamic, traceable group encryption system.

[0033] Based on the above technical solutions and the technical problems they solve, please analyze the advantages and positive effects of the technical solution to be protected from the following aspects:

[0034] First, addressing the technical problems existing in the aforementioned prior art and the difficulty of solving them, this technical solution, closely integrating the technical solution it seeks to protect with the results and data from the research and development process, provides a detailed and in-depth analysis of how this technical solution solves the technical problems and the innovative technical effects it brings after solving these problems. The specific description is as follows:

[0035] Existing traceable group encryption is difficult to implement in email systems, mainly due to two conflicting sets of contradictions: frequent member changes require support for continuous joining / removal without resetting parameters; business governance demands "default anonymity and traceable authorization," while confidential scenarios require stronger statistical anonymity to weaken recipient distinguishability. These two constraints make it difficult for the system to balance usability, privacy, and compliant tracking.

[0036] This technical solution proposes an integrated implementation approach: First, it introduces a positive dynamic accumulator to achieve evolvable member management. When a user joins the group, a key and a tracking trapdoor are generated locally, and the user submits a public key, encryption of the trapdoor, and a zero-knowledge proof. After verification by the administrator, an identifier is assigned and a member witness is issued. Group information is periodically published to support publicly verifiable activity status determination. When a user is revoked, the corresponding identifier is removed from the accumulator through an update algorithm, and new group information is published, achieving dynamic joining and revocation without resetting parameters. Second, it adopts a "content-recipient identifier separation" encryption architecture: the message content is encrypted and protected with a public key that has CCA security and key privacy; the recipient identifier is bound to a one-time verification key and then encrypted and encapsulated with a lossy public key that has CCA security, and the form is controlled by a predicate policy—the normal mode is an openable lossless form to support compliant tracking, and the high anonymity mode degenerates into a lossy form for all zeros, making the identifier statistically independent of the recipient. Third, a controllable and verifiable anonymous tagging system is introduced, attaching switchable anonymous tags to encrypted text: a regular mode allows for controlled tracking under authorization, while a high-anonymity mode provides strong concealment; simultaneously, a publicly verifiable declaration is provided to prove "I am / am not the legitimate recipient corresponding to this tag," supporting dispute resolution and liability determination. The innovative effects of this technical solution are mainly reflected in three points:

[0037] 1) Supports dynamic addition and removal of members, transforming member changes into publishable and verifiable group status updates. This allows the system to continue operating without resetting global parameters or performing large-scale re-encryption when members change frequently, significantly reducing operational complexity and maintenance costs.

[0038] 2) Achieve a balance between statistical anonymity and traceability. In confidential scenarios, make the identifiers statistically indistinguishable to obtain stronger anonymity protection. In regular scenarios, retain authorized, accessible, and traceable clues, thereby balancing privacy protection and compliance governance within the same framework.

[0039] 3) Achieve a verifiable governance loop, enabling verifiable checks on the validity of encrypted text and policy compliance without decrypting the main text, thus achieving access control; at the same time, combined with a declarative mechanism, it provides reliable support for auditing, evidence collection, dispute resolution, and liability determination.

[0040] Secondly, the supporting evidence of inventiveness for the claims of this technical solution is also reflected in the following important aspects:

[0041] (1) This technical solution is aimed at encrypted email systems and integrates “full dynamic management of members, unified anonymity and traceability according to policy, and verifiable governance on the gateway side” into a set of cryptographic infrastructure capabilities that can be implemented. The expected benefits and commercial value of this transformation are mainly reflected in the following aspects: First, in situations where employees frequently join, change positions, or leave, the system can continuously evolve through publicly verifiable member status updates without resetting global parameters or performing large-scale re-encryption, thereby significantly reducing deployment and maintenance costs and minimizing downtime. Second, the gateway can complete access control and verifiable policy checks without decrypting the email body, and can provide a traceable and declarable chain of evidence when legally compliant and authorized, improving the efficiency of compliance auditing and risk management, and reducing the overall costs of handling abuse, investigating internal threats, and responding to account hijacking. Finally, these capabilities enable enterprises to achieve a balance between "strong encryption" and "governability," enhancing their confidence in the long-term usability, auditability, and compliance of the encryption system. This facilitates the promotion of encrypted email and related security products in highly sensitive industries such as finance, government, healthcare, and scientific research, and further develops into productizable security gateways, encrypted email suites, or key management services, possessing clear practical value and scalable replication potential.

[0042] (2) Encrypted emails have long been stuck in a "three-pronged dilemma": routine business needs to hide the recipient's identity and communication relationship from the outside world and maintain an anonymous appearance; compliance authorization and secure operation require verifiable traceability and evidence; confidential scenarios need to further enhance the recipient's anonymity to a statistical significance. Traditional solutions often only offer two options: sacrifice anonymity for governance, or give up tracking and evidence output for anonymity, resulting in insufficient auditing and response capabilities. This technical solution achieves a balance between statistical privacy and traceability by "switching lossy / lossless encryption modes according to a strategy" so that identity information is automatically "hidden" when stronger privacy is needed, while retaining verifiable and traceable clues when governance and accountability are needed. Attached Figure Description

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

[0044] Figure 1 This is a flowchart of the privacy-enhanced, fully dynamic, traceable group encryption method provided in this technical solution embodiment.

[0045] Figure 2 This is a block diagram of the privacy-enhanced, fully dynamic, traceable group encryption system provided in this embodiment of the technical solution. Detailed Implementation

[0046] To make the objectives, technical solutions, and advantages of this technical solution clearer, the following detailed description is provided in conjunction with embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the technical solution and are not intended to limit the scope of the technical solution.

[0047] like Figure 1 As shown in the figure, the privacy-enhanced, fully dynamic, traceable group encryption method provided in this embodiment of the technical solution includes the following steps:

[0048] S101, Establish an Anonymous Tag System with Controlled Traceability and Claimability (ATCTC).

[0049] S102, system initialization, and ATCTC is called to generate public parameters and keys for the group manager (GM) and open authority (OA), and initialize group information and public registry.

[0050] S103: When a new user joins, an interaction protocol is executed with the GM, and the ATCTC is called in addition. The GM verifies the user's membership and issues a group member certificate.

[0051] S104 When a member is removed or the member set changes, GM generates and publishes new group information, enabling the system to support dynamic member removal without resetting global parameters.

[0052] S105, during encryption, the sender inputs public parameters, GM public key, OA public key, group receiver public key, group information, plaintext message, tag, witness, and predicate, and calls the ATCTC system to generate ciphertext.

[0053] S106, the sender generates a proof to demonstrate that the ciphertext format is correct, it was generated for a currently active group member, its intended receiver can recover the message, and the message satisfies certain public policies. The verifier checks the proof; if valid, it outputs 1; otherwise, it outputs 0.

[0054] S107, during decryption, the group receiver inputs the private key, public parameters, ciphertext, and tag. If the ciphertext is indeed what it expected to receive, the plaintext is recovered; otherwise, a failure symbol is output.

[0055] S108, when tracing ciphertext, the opener can perform an open operation on a certain ciphertext. If the ciphertext supports tracing, the active user identity corresponding to the ciphertext is output. If ciphertext tracing is performed on a group of users, the opener can obtain the tracking credentials of the group of users, call ATCTC, verify any ciphertext, and determine whether the ciphertext was indeed sent to the user.

[0056] S109, with the user possessing their own key, the user can call ATCTC to generate a publicly verifiable evidence for a given anonymous ciphertext, which can convincingly prove whether the ciphertext was indeed sent to them as a legitimate ciphertext; any third party can independently verify this evidence after obtaining it.

[0057] like Figure 2 As shown in the figure, the privacy-enhanced, fully dynamic, traceable group encryption system provided in this embodiment of the technical solution includes:

[0058] ATCTC system module 1 is used to build the ATCTC system;

[0059] System Module 2 is used to generate public parameters and keys for GM and OA, and to initialize group information and the public registry.

[0060] User addition module 3 is used to introduce new group members;

[0061] User cancellation module 4 is used to cancel group members;

[0062] Encryption module 5 is used to encrypt messages and generate ciphertext;

[0063] Proof module 6 proves that the ciphertext format is correct, that it was generated for a group member who is still active, that its intended recipient can recover the message, and that the message satisfies certain public policies.

[0064] Decryption module 7 is used to decrypt ciphertext and output plaintext or error symbols. ;

[0065] The tracking module 8 is used to track the ciphertext. If the ciphertext supports the tracking function, the identity of the recipient of the ciphertext can be obtained; otherwise, the ciphertext remains anonymous.

[0066] Declaration module 9 is used to generate a publicly verifiable evidence of an anonymous ciphertext, which convincingly proves whether the ciphertext was indeed sent to oneself as a legitimate ciphertext.

[0067] The technical solution of this invention will be further described below with reference to specific embodiments.

[0068] This technical solution achieves full dynamic group encryption while coordinating statistical receiver anonymity and traceability, making it more suitable for practical applications. Table 1 summarizes the functional characteristics of the privacy-enhanced, fully dynamic, traceable group encryption scheme proposed in this technical solution and representative GE schemes. It can be seen that all listed schemes can guarantee message confidentiality; however, only the scheme proposed in this technical solution and the scheme by Libert et al. simultaneously support traceability and assertion / denial mechanisms. User revocation is supported by the schemes of Nguyen et al., Pan et al., and this technical solution. It is particularly noteworthy that only this technical solution provides traceability while also achieving statistical receiver anonymity, thus balancing privacy and accountability. Furthermore, the work of Kiayias–Tsiounis–Yung and this technical solution belongs to a general framework, rather than simply modular assembly. Overall, the privacy-enhanced, fully dynamic, traceable group encryption scheme of this technical solution provides richer and more comprehensive functional characteristics.

[0069] Table 1 Comparison of features with group encryption schemes

[0070]

[0071] *AA—Accountable Anonymity: Group members remain anonymous by default unless their identities are disclosed by an authorized opening authority; BA—Bifurcated Anonymity: The system allows encryption based on predicates. By making a "bifurcation" choice, the ciphertext can acquire statistical anonymity or traceable anonymity.

[0072] 1: Controllable tracking and declared anonymous tagging system

[0073] 1.1 Formal Definition

[0074] Definition 5: An anonymous tag system with controlled traceability and claimability (ATCTC) includes the following algorithms:

[0075] (1) Input security parameters The algorithm outputs common parameters. ;

[0076] (2) Input common parameters The key generation algorithm outputs key pairs. .

[0077] (3) The tag generation algorithm outputs a tag. ; when integer hour, For traceable tags, when At this time, it is an untraceable tag.

[0078] (4) The algorithm outputs the public key. Corresponding tracking trapdoor .

[0079] (5) The tracking algorithm is in It is related to the public key Output when relevant traceable tags are available Otherwise output .

[0080] (6) The algorithm outputs publicly verifiable evidence. Used to indicate the label Is it in the public key? The generated (i.e., declared or denied) below.

[0081] (7) The algorithm declares evidence. Output when valid Otherwise output .

[0082] (8) The algorithm denies evidence. Output when valid Otherwise output .

[0083] This technical solution specifies the following correctness requirements: After system initialization and key generation, when a tag is generated by a public key in a specified mode, all algorithms within the system should coordinate consistently and produce the expected output. The probability of any deviation from the expected output should be negligible. Specifically: When a tag is generated using a public key in "traceable mode," verification using the tracking trapdoor corresponding to that public key should result in a "match," while verification using the tracking trapdoor corresponding to any other public key should result in a "mismatch." When a tag is generated using a public key in "untraceable mode," even verification using the tracking trapdoor corresponding to that public key should fail to match, thus maintaining untraceability. Furthermore, for any tag generated by a public key, the claim evidence generated by the legitimate recipient based on their own private key should pass the claim verification; for any tag, the denial evidence generated by the non-corresponding public key side based on their own private key should also pass the denial verification. The above consistency and passability are based on the "negligible failure probability" as the correctness criterion.

[0084] 1.2 Security Model

[0085] This technical solution first presents an indistinguishability security model: Under given security parameters, a polynomial-time adversary can corrupt all participants except the target receiver and perform restricted queries on the system's provided interface, including requesting the generation of several tag public keys, requesting corresponding secret keys for some public keys, and requesting trapdoors for some public keys; the system maintains query records to impose challenge constraints. In the challenge phase, the adversary selects a challenge public key previously generated by the system and provides two different pattern bits (representing traceable and untraceable forms, respectively); the system randomly selects hidden bits, runs the tag generation algorithm according to the selected pattern to generate challenge tags, and returns them. The adversary can then continue querying, but must not request secret keys or trapdoors for the challenge public key; otherwise, the query fails. Finally, the adversary outputs a one-bit guess of the challenge tag's pattern, with a success probability at most one negligible amount higher than random guessing.

[0086] This technical solution further provides an anonymity security model: Under given security parameters, a polynomial-time adversary can corrupt participants other than the target receiver and perform restricted queries on the system-provided interface. These queries include requesting the generation of several tag public keys, requesting corresponding secret keys for some public keys, requesting trapdoors for some public keys, and initiating association verification queries on some "public key-tag" pairs. The system maintains records of public key generation, private key queries, trapdoor queries, and association verification queries to impose challenge constraints. During the challenge phase, the adversary selects two challenge public keys previously generated by the system. And give a one-bit mode The system randomly selects hidden bits. ,by and pattern The tag generation algorithm is run to produce challenge tags and return them. Adversaries can then continue querying, but may not... or Requesting secret keys or tracking traps is also prohibited. or Initiate a related verification query; otherwise, the query fails. The final adversary outputs a one-bit guess of the public key index corresponding to the challenge tag, with a success probability at most one negligible increment higher than random guessing.

[0087] This technical solution further provides a robust security model: Under given security parameters, a polynomial-time adversary can generate several tag public keys through the system interface and, under constrained conditions, request secret keys for some of these public keys or initiate association verification queries for some "public key-tag" pairs; the system records these queries to constrain the adversary's capabilities. The adversary then attempts to output a public key, a tag, and a statement or denial evidence. If the public key was indeed generated by the system and the adversary has never queried the secret key of this public key, and the adversary has not performed an association verification query on the combination of the public key and the tag, but the evidence provided can still pass the system's statement or denial verification, then the adversary is considered successful, and the experiment outputs a successful event. If the probability of any adversary causing this successful event to occur is at most negligible, then the scheme is said to satisfy robustness, that is, without possessing the corresponding secret key and without relying on the verification interface, it is impossible to forge verifiable statement or denial evidence.

[0088] 1.3 A specific construction

[0089] 1)

[0090] ① Generate the bilinear group ,in and It is a prime number. cyclic group yes random generator, It is a bilinear mapping that randomly selects group elements. and set vector .

[0091] ② Order For some polynomial, for integers arrive Randomly select an integer Set vector

[0092] ,

[0093] Thus, a vector set is obtained. , This is the multiplication symbol.

[0094] ③ Choose a one-time signature scheme that is highly resistant to forgery. and a family of chameleon hash functions The key pair is The hash function is .

[0095] ④ Output common parameters .

[0096] 2)

[0097] ① Randomly select an integer Calculate group elements .

[0098] ② Output key pair .

[0099] 3)

[0100] ① Input public parameters Public key integer Auxiliary information random numbers .

[0101] ② Generate a one-time signature key pair .

[0102] ③ Randomly select an integer , where integer And calculate group elements .

[0103] ④ Output tags .

[0104] 4)

[0105] ① Calculate group elements .

[0106] ② Return the public key Tracking trap .

[0107] 5)

[0108] ① will Parsed as and will Parsed as .

[0109] ② Verification Check if it is a valid one-time signature and whether it meets the requirements. If all the above conditions are true, output 1; otherwise, output 0.

[0110] 6)

[0111] ① Public key Parsed as , private key Parsed as and will Parsed as .

[0112] ② Verification Check if it is a valid one-time signature, and verify that... Check if the above conditions are true. If all the above conditions are true, proceed to the next step; otherwise, output the result. .

[0113] ③ Calculate group elements .

[0114] ④ Select random numbers Calculate hash value .Will Analysis and calculate vector ,

[0115] ⑤ This forms a Groth-Sahai public string. This public string will be used for group elements.

[0116] Generate a commitment And a question about satisfy The NIZK proof. Therefore, for auxiliary variables... Generate a commitment And generate a non-interactive proof of the following equations. :

[0117] , (1),

[0118] ⑥ Output proof , .

[0119] 7)

[0120] 1) Public key Parsed as , label Parsed as And will prove Parsed as .

[0121] 2) Return 1 if and only if the following conditions are met simultaneously: signature A valid one-time signature; relationship It is established; and it is proven It is a valid proof of relation (1), and is relative to the common reference string. Given, where the vector Otherwise, return 0.

[0122] 8)

[0123] 1) Public key Parsed as ,Will Parsed as And will prove Parsed as .

[0124] 2) Return 1 if and only if the following conditions are met simultaneously: signature A valid one-time signature; relationship It is established; and it is proven It is a valid proof of relation (1), and is relative to the common reference string. Given, where the vector Otherwise, return 0.

[0125] 2. Privacy-enhanced, fully dynamic, traceable group encryption

[0126] 2.1 Syntax Definition

[0127] In form, a public relations The verifiable privacy-enhanced and fully dynamic traceable group encryption (PFTGE) scheme consists of the following algorithms.

[0128] (1) The algorithm consists of three sub-procedures, as follows:

[0129] 1) Given security parameters This process outputs a set of common parameters. .

[0130] 2) This process is by Execute and output key pair .

[0131] 3) This process is by Execute and output key pair .

[0132] at last, and Interaction to establish group public key During this process, group information is also initialized. and public registry .

[0133] (2) This interaction protocol is initiated by a user who is to join (holding a key pair). )and In the current period To be jointly implemented. and All inputs include ,in An additional master key is required. Once the protocol is successfully completed, the user receives a unique group identifier. A pair of keys and a member's evidence .at the same time, Interaction history Recorded to the public registry In the middle, update the group information.

[0134] (3) The algorithm is composed of Execution is used to update group information and advance the period to... Given the master key A set of active users to be removed from the group Current group information and the registry The algorithm outputs updated group information. And refresh the table accordingly. .

[0135] (4) Randomization algorithm Enter security parameters At that time, for the relationship Generate public and secret parameters .if If it is publicly available for sampling, then It can be empty. Given Probabilistic Algorithm Output a pair ,in For public statements, Witness it. Polynomial-time decision algorithm. In the input When, if and only if Output 1 when the time is right.

[0136] (5) :enter ,Label ,witness and predicates The algorithm outputs ciphertext. and its associated tags ( This is the public string bound to the ciphertext, often referred to as its text. It can encode auxiliary information or transaction-related data (such as identifiers, timestamps, or protocol-related metadata), or it can be empty. Binding to ciphertext ensures that the ciphertext is interpreted only within its intended context, thus preventing cross-context misuse. (And the random number used in the encryption process.) If the public key During the period Inactive, or The algorithm outputs .

[0137] (6) This is an interactive protocol between the sender (provider) and the verifier. The proof algorithm is executed by the sender. Output a proof Used to prove ciphertext It is in the correct format and is period-oriented. The message is generated by a currently active group member, and the recipient is expected to be able to retrieve it. , making A verification algorithm executed by any verifier. In proof Output 1 if valid, otherwise output 0.

[0138] (7) The decryption algorithm is controlled by the holder of the secret key. The user executes the command and outputs a message. ,if Otherwise, output .

[0139] (8) The opening algorithm is determined by the opener. Execute, and output an active user identifier. If opening fails, output: .

[0140] (9) Given the secret key and users Adding interaction records The algorithm for revealing this information is provided by the opener. Execute and return to user Tracking trap .

[0141] (10) The tracking algorithm is provided by the opener. Execution: If It is sent to the user If the ciphertext is valid, output 1; otherwise, output 0, indicating that the tracing has failed.

[0142] (11) These algorithms enable users to persuasively declare or deny that they are anonymous. The legitimate recipient. Specifically, the algorithm By holding the user key pair One party operates the system and outputs publicly verifiable evidence. , used to prove Is it a public key? The following is a valid encryption method. Subsequently, the algorithm... Upon receiving evidence of assertion / denial Then verify: if it is valid, output 1, otherwise output 0.

[0143] Correctness: This technical solution constrains and verifies the behavior of the above algorithm combination by constructing an overall correctness experiment. It requires that when the system executes according to the specifications and all inputs satisfy the relational constraints and member active state conditions, the following properties must simultaneously hold: For ciphertext generated by Enc and verified by P / V, the receiver calling Dec should correctly recover the original message; when tracing is allowed in privacy mode, Open and Trace should be able to recover and confirm the correct receiver identifier; in modes where tracing is not allowed, Open and Trace should fail or not reveal identity information; for legitimate receivers, their "I am" proof generated by the algorithm should pass verification; for non-receivers, their denial proof should pass verification.

[0144] 2.2 Security Model

[0145] This technical solution first presents a security model for message confidentiality, characterized using an adversary-challenge experiment. Specifically, given security parameters, it assumes the existence of a polynomial-time adversary who can corrupt other system participants besides the intended recipient (e.g., group administrators, verifiers / gateways, openers, and some group members), and, under certain conditions, invoke system-provided interfaces (such as member addition and removal, encryption and verification, decryption, opening and tracking, declaration / denial, and other query capabilities). In the challenge phase, the adversary specifies a message input satisfying given relational constraints, and the system generates a corresponding challenge ciphertext. The system randomly selects one of two cases—"real plaintext" or "random plaintext"—to generate and return the ciphertext. After further access to the relevant interfaces, the adversary outputs a bit as a guess.

[0146] This technical solution decomposes the anonymity objective into two complementary scenarios in the security model, formally proposing the "forked anonymity" requirement, and characterizing and proving it through challenge experiments. Specifically, in the traceable scenario (predicate not identically equal to 1), assuming the attacker possesses polynomial-time computation capabilities, can completely corrupt the group administrator and corrupt all group members except the two challengers in any way, while also invoking oracle interfaces such as member joining, ciphertext decryption, ciphertext opening, tracing trapdoor generation, and declaration / denial; under this condition, the attacker should still be unable to effectively distinguish challenge ciphertexts generated under the two challenge public keys, and their success advantage in guessing the identity of the ciphertext receiver in the corresponding anonymity game should be at most 1 / 2 plus a negligible amount. In the untraceable scenario (predicate is always 1), this technical solution further enhances the attack model: in addition to the above capabilities, it also allows the attacker to corrupt the opener and obtain their entire key state; even so, the attacker's advantage in distinguishing the two challenge receivers in the corresponding anonymity game should still not exceed 1 / 2 plus a negligible amount, thus maintaining the concealment of the ciphertext receiver's identity under a stronger adversary model.

[0147] This technical solution introduces a "robustness" objective into the security model to characterize the system's correctness and anti-forgery capabilities during the tracking and governance phases. Intuitively, robustness requires that no attacker can construct a seemingly legitimate ciphertext and its proof, yet cause inconsistencies between identity extraction and tracking results, or bypass the system's constraints on active members, public key legitimacy, and ciphertext legitimacy. Formally, in the robustness experiment, the attacker first obtains the system's public parameters, as well as the group administrator's secret state and the opening party's secret key generated by a simulation algorithm. They can then register any user under their control via a registration oracle, maximizing their influence on the system's registration process and group information. Subsequently, the attacker outputs a ciphertext to be verified, the corresponding proof, and related public keys, tags, and auxiliary information. If the ciphertext passes the public verification algorithm, the system further calls the extraction algorithm to obtain the candidate group member identifier and supporting evidence, and checks whether the following conditions are simultaneously met: the public key corresponding to the identifier belongs to the legitimate user key set and is active; the ciphertext is indeed a valid ciphertext language; and after calling the opener's reveal and trace algorithm, the trace result obtained is consistent with the extracted identifier under predicate judgment. Robustness requires that the probability of an arbitrary polynomial-time attacker successfully making the above checks "pass while violating any condition" is at most negligible.

[0148] This technical solution further introduces the "declaration robustness" objective into the security model to characterize the unforgeability and controllability of the declaration / denial mechanism. Specifically, in the considered security experiment, the adversary first obtains the system's public parameters and the relevant states of the group administrator and opener by simulating the initialization algorithm. Subsequently, the adversary can act as the group administrator to initiate member registration and flexibly invoke member registration, member corruption, decryption, and declaration / denial capabilities through the oracle interface, thereby approximating the most powerful realistic attack scenario as closely as possible. Under this attack model, the robustness requirement is that even if the adversary has corrupted the group administrator and the opener, and gained access to all permitted oracles, it is almost impossible to construct a verified ciphertext and its proof, and then give a "declaration / denial" statement about a public key such that any of the following conditions still hold true: ① For a public key that is registered but not the challenger's, it is verified as a "valid declaration seemingly given by the user"; ② For the public key corresponding to the challenger, it is verified as a "valid denial seemingly given by the user"; ③ For an honest public key that has not been corrupted, a declaration or denial evidence that has been verified but was not generated by the declaration / denial interface is given.

[0149] 3. Proposed privacy-enhanced, fully dynamic, traceable group encryption scheme

[0150] 3.1 General Construction

[0151] This technical solution presents a general PFTGE construct. In addition to the controllable tracking and declarative anonymous tagging system introduced in 1.1, this technical solution also uses the following components: a one-time signature scheme. CCA2 security for inequality relationships Encryption scheme A CCA2-secure lossy public-key encryption scheme A homomorphic scheme with equivalent commitments A positive dynamic accumulator scheme A public-key encryption scheme with CCA2 security and key privacy. and a CCA2-secure public-key encryption scheme. A dual-mode statistical NIZK proof system .

[0152] (1) Enter security parameters The algorithm is executed as follows:

[0153] 1) The algorithm performs the following steps:

[0154] Set the maximum possible number of group users to an integer. and order Represents a set The bit length of each element. Select a predicate family. Its depth is The circuit family characterization; and the selection of witness space. , where integer Choose a one-time signature scheme. Its verification key space is , where integer .run Get parameters This allows us to determine the key space and the tag space. and message length Then select the initial value. and execute Generate a lossy key pair .run Get parameters Operation key and master key .run Generate parameters By running Generate a common reference string for bimodal NIZK proofs in statistical zero-knowledge mode. and auxiliary values Finally, the following set of common parameters is output:

[0155]

[0156] 2) This algorithm is developed by the group administrator. The specific steps for execution are as follows:

[0157] run Algorithm, generating public parameters Key and the initial value of the accumulator Initialize the registry. , where array Used to store the Records of registered users And array and Record the periods when the user joins and leaves the group. Simultaneously, initialize the registered user counter. Output key pair Public Registry With initial group information , where the counter Depend on Keep it safe yourself. Please note that only those who possess it are permitted to keep it. Only entities that meet the requirements are allowed to update and republish. and .

[0158] 3) This algorithm was opened by the user. The execution is as follows.

[0159] run Generate key pairs and run Generate key pairs Output secret key and public key .

[0160] (2)

[0161] 1) A person who hopes to be in the period Users joining the group should follow these steps: First, generate a key pair. and key pair Set the secret key to The public key is set to Next, a tracking trapdoor is generated. Then generate a random number. Calculate ciphertext And generate an NIZK proof. ,prove It is indeed encrypted. Finally, the user will Send to .

[0162] 2) Check the registry If a record already exists in it Make the public key Then return .otherwise, In public key Encrypt a random message Obtain the ciphertext and will Send to the user.

[0163] 3) User usage For ciphertext Decryption yields the message and will Forward to .

[0164] 4) If message ,but Reject the joining request. Otherwise, Continue with the following steps: First, in the set Randomly select an identifier ,in This represents the set of elements that have been accumulated, and the identifier is... Distribute to users. Then run the algorithm. Get the updated accumulator and corresponding member testimonies And require users to set their public key to Calculate a collision-resistant hash value. and in Lieutenant General's Interaction Log Recorded as , At the same time, update the set to For each element , Through witness Update its member testimonies. Finally, Will Send to the user to update the counter value. And update the group information to .

[0165] (3)

[0166] 1) Let set Includes the identifiers of all registered users whose qualifications will be revoked. If ,but Directly publish group messages in the new era Otherwise, proceed to step 2.

[0167] 2) For all identifiers Running the algorithm The new accumulator value is obtained. and update messages Then, for each identifier Let the array and update the set to .at last, Announcement of updated group information .

[0168] (4)

[0169] algorithm For relationship Sample generation parameter pairs .algorithm enter Output a pair that satisfy of .

[0170] (5)

[0171] The algorithm is executed by the sender and is used in the current period. Below, for a selected user Encrypt a single statement to satisfy News Predicates are used during encryption. The corresponding witness ,in Let it be an integer. For a Boolean circuit, its depth is at most 0. , The input is an integer. Time calculation predicate The value of , where Public key Parsed as Download the latest group information. From this, the cumulative value is obtained. With witness Then the algorithm is called. Check identifier Is it during the period? Still an active group member. If verification passes, then... And continue with the following steps:

[0172] 1) Running the algorithm Obtain a one-time signature key pair .

[0173] 2) Select random numbers and in public key Below, tagged as Encryption in the case of Generate ciphertext

[0174] (2);

[0175] 3) Select random numbers and calculate commitments ,prove and commitment

[0176] (3),

[0177] ,

[0178] .

[0179] 4) Select random numbers , let value And calculate the ciphertext

[0180] (4),

[0181] ,

[0182] 5) Select random numbers and calculate traceable components

[0183] (5),

[0184] Among them, when At that time, the component ensures that the ciphertext can be associated with its intended recipient through the corresponding tracking trapdoor.

[0185] 6) Select random numbers , make the label and in public key and tags Encrypted messages Generate ciphertext

[0186] (6),

[0187] 7) Define the ciphertext as The signature

[0188] Output and random numbers .

[0189] (6)

[0190] 1) The sender constructs a prove To convince the validator that the following facts are true: the message satisfy And there are random numbers. Circuit output and proof This makes relations (2)–(6) and the following conditions simultaneously true:

[0191] (7),

[0192] (8),

[0193] 2) Verifiers obtain group information and ciphertext Parsed as , If and only if the signature It is a valid one-time signature, and evidence. It is an effective Output 1 if the proof is successful; otherwise output 0.

[0194] (7)

[0195] User's private key Parsed as , ciphertext Parsed as

[0196] Verify signature Is it a valid one-time signature? If the verification passes, the receiver calculates the message. .if Satisfying Relationships Then output Otherwise, output .

[0197] (8)

[0198] Opener's private key Parsed as and the group administrator's public key Parsed as From group information take out . ciphertext Parsed as Verify signature Is it a valid one-time signature? If verification passes, the opener... Calculate bit value If the bit value Then return Otherwise, from the identifier Recovery And check: (i) binary value (ii) If all the above conditions are met, then return. Otherwise return .

[0199] (9)

[0200] Opener's private key Parsed as Transaction records Parsed as .verify Is it targeting Valid proof. If passed, then by Calculate the trapdoor .

[0201] (10)

[0202] ciphertext Parsed as and verify the signature. Is it a valid one-time signature? If the verification passes, then it is valid if and only if... At the time of its establishment, by Output 1; otherwise output 0.

[0203] (11)

[0204] 1) Pass the private key Parsed as , public key Parsed as Then send the ciphertext Parsed as Verify signature Is it a valid one-time signature? If verification passes, user evidence. As evidence of assertion / denial.

[0205] 2) If and only if or If accepted, output 1; otherwise, reject (output 0).

[0206] 3.2 Pair-based Instantiation

[0207] 3.2.1 Select the CCA2 safety label - Lossy public-key encryption scheme

[0208] (1)

[0209] Input security parameters Define the initial value space tag collection and message space , where integer Output public parameters .

[0210] (2)

[0211] Input public parameters and initial value Generate a bilinear group Select two group elements. and make group elements , where integer Randomly sampled integers And calculate group elements , , , , Define a vector ,vector ,vector ,in Randomly sampled integers and calculate vector , where the initial value Interpreted as One of the elements. Output an injective key pair. ,in ,and .

[0212] (3)

[0213] The algorithm and It is exactly the same, except that in step 1), it makes the vector .

[0214] (4)

[0215] 1) Enter the public key ,Label ,information For each integer Randomly sampled integers And calculate the ciphertext , , , among which tags Interpreted as One of the elements.

[0216] 2) For each integer Return ciphertext and output ciphertext .

[0217] (5)

[0218] 1) Pass the ciphertext Parsed as Each ciphertext The algorithm outputs if any of the following conditions are met. : ,or ,or Otherwise, for each ,like ,make Otherwise, 1

[0219] 2) Finally, output the message. ,in Interpreted as One of the elements.

[0220] 3.2.2 Pair-based PFTGE construction

[0221] set up Let f(x) denote a symmetric bilinear group, where f(x) = f(x) and It is a prime number. cyclic group yes The random generator. The instantiation based on the bilinear group in this technical solution follows the same paradigm as the general framework. Specifically, this technical solution uses the following cryptographic tool: a strongly unforgeable one-time digital signature scheme. A CCA2 secure - Lossy encryption scheme By selecting the CCA2 security label - Instantiated by combining a lossy public-key cryptographic construct with a strong, unforgeable one-time signature scheme; a CCA2-secure lossy cryptographic scheme. For simplicity, this technical solution also adopts CCA2 security. - Instantiated using a lossy public-key cryptographic construct, with only the following unique modification: for any ,make A homomorphic equivalent commitment scheme with efficient verification is denoted as . A positive dynamic accumulator scheme This technical solution follows relevant methods, using the structure-preserving AHO signature as a positive additive accumulator and combining it with a non-adaptive robust positive dynamic accumulator to obtain an adaptive robust construction; Shacham proposed a linear Cramer-Shoup encryption scheme that simultaneously satisfies CCA2 security and key privacy; Kiltz proposed a label-based encryption scheme that satisfies CCA2 security; and a bimodal statistical NIZK proof system, which is instantiated using the Groth-Sahai proof system.

[0222] In the public group elements Below, for satisfaction News Encryption is performed. The group administrator's public key is used. Parsing yields the identifier as well as .

[0223] 1) Generate a one-time signature key pair .

[0224] 2) For each integer Random sampled integers and in the label Below, for the identifier – proof of the pair Calculate one Lossy encryption:

[0225] (9),

[0226] Finally, the ciphertext .

[0227] 3) Set common parameters Parsed as Randomly sampled integers And calculate commitments (10),

[0228] Next, the HEC evaluation algorithm is applied to generate the proof. and promises For certain public group elements and group elements , must meet

[0229] , (11),

[0230] Among group elements Can be derived from integers It was calculated efficiently.

[0231] 4) For each integer Random sampled integers Let the bit value bit string Then calculate the ciphertext.

[0232] (12),

[0233] Finally, the ciphertext .

[0234] 5) Given public parameters Public parameters included Randomly sampled integers and constrain integers Then calculate the group elements. (13),

[0235] Finally, the ciphertext .

[0236] 6) Random sampling of random numbers and in the label Next, calculate the Shacham linear Cramer-Shoup pair message. Encryption, generating ciphertext

[0237] (14),

[0238] Hash value .

[0239] 7) Command ciphertext The signature Return ciphertext and tags and output random numbers. ,

[0240] The prover hopes to convince the verifier, with zero knowledge, that their private inputs satisfy the equation.

[0241] (15),

[0242] (16),

[0243] (17),

[0244] Furthermore, all equations in (9)–(14) hold true. This technical solution notes that the Groth–Sahai bimodal proof system needs to be instantiated twice: once to prove the satisfiability of scalar product equations, such as (9), (10), and (12), in which a commitment to the scalar is required; and again to prove the satisfiability of paired product equations such as (11) and (15)–(17), in which a commitment to the group elements is required. In addition, it is necessary to prove the consistency between the committed values ​​in the two instances, specifically regarding bit values. and group elements In Consistency, and about elements With circuit value middle Consistency. Proof. Ultimately includes Individual group elements.

[0245] 4: Performance Analysis

[0246] This technical solution provides a more detailed comparison between its specific implementation scheme and existing pair-based group encryption schemes in terms of both functional characteristics and efficiency.

[0247] Table 2 Comparison of features with related schemes

[0248]

[0249] Table 2 compares the available functionalities for GM, OA, and group users in the Cathalo scheme, Libert scheme, and the instantiation scheme of this technical solution, as well as the components used in each scheme. Only this technical solution simultaneously grants GM members the ability to join and revoke. Furthermore, this technical solution and the scheme of Libert et al. allow OA to open ciphertext and publicly track all ciphertexts associated with a given user without decrypting each ciphertext individually. However, the construction of this technical solution provides stronger privacy: whether each ciphertext can be opened and tracked is determined by the sender at the time of encryption.

[0250] Table 3 compares the efficiency of related schemes.

[0251]

[0252] Table 3 further provides a more detailed efficiency comparison between the specific instantiation scheme and existing pairwise group encryption schemes. For this comparison, the present invention considers an 80-bit security level and employs a symmetric bilinear group instantiated from the SS512 elliptic curve. The present invention uses the one-time signature scheme from Groth et al.: in this scheme, the verification key... and signature It consists of 3 and 2 group elements respectively; therefore Bits. Note the identity identifier. belong Therefore, this invention takes Bit. Furthermore, witness. It is a context-independent string, which can be intuitively viewed as relative to the predicate. For group users The "evidence" provided by the received encrypted text. Here, the present invention makes a simple assumption. . Specifically, when Time, predicate Output 0; otherwise, output 1. Clearly, the solution of this invention does require higher storage and communication overhead. In particular, the storage cost borne by the group users in this invention is close to the overhead of Catharo et al.'s solution. Furthermore, in the solution of this invention... The public key size is smaller than that of Catharo et al.'s scheme, but larger than that of Libert et al.'s scheme.

[0253] Example 1: Implementation of System Establishment and Dual-Role Key Generation

[0254] In this embodiment, the system first establishes a traceable and declarative anonymous tagging system. Based on security parameters, the system generates a bilinear group and public parameters, constructs a public string for tag generation and verification, and generates a one-time signature and chameleon hash parameters, binding the anonymous tag to the one-time signature and providing anti-forgery capabilities. Subsequently, the group administrator generates a master key and public information for dynamic member management, while the opener generates a secret key and public key for opening and tracking. The group's public information is published to a public registry, and the group information is initialized to empty or an initial accumulator state, thus forming a unified public input for subsequent join, revoke, encryption, open, and declaration operations. The system publicly discloses only the public parameters, the group administrator's public information, the opener's public information, and the public registry structure; the group administrator's master key and the opener's secret key are stored independently. This separate design ensures that no single entity can simultaneously complete member updates, identity opening, and declaration generation. Following the above process, a third party can reproduce the public parameter initialization and key generation to obtain a runnable system state, providing a consistent input interface and verifiable conditions for subsequent embodiments.

[0255] Example 2: Implementation of Member Addition and Registry Writing

[0256] In this embodiment, when a new user joins, two types of keys are generated locally: a public-private key pair for email decryption and a public-private key pair for the anonymous tagging system. The user calculates a tracking trapdoor based on the tag's public key and encrypts it with the opener's public key to form the trapdoor ciphertext. Simultaneously, publicly verifiable proof of correctness is generated, demonstrating that the ciphertext indeed carries a valid tracking trapdoor. The user then submits the received public key, trapdoor ciphertext, and proof to the group administrator. The group administrator first checks for duplicate registrations in the public registry and then confirms through a challenge-response process that the applicant indeed possesses the corresponding private key to prevent impersonation. After successful verification, a unique member identifier is assigned to the user, and a member witness is issued, used to subsequently prove their valid membership status at the current time. After joining, the group administrator writes this registration to the public registry and updates the group information, allowing other participants to obtain the latest member validity data. The user output includes the member identifier, member witness, and the bound public key structure. This structure serves as the receiver's identifier input in the subsequent encryption stage, thus achieving a connection between verifiable registration and subsequent revocable member management.

[0257] Example 3: Implementation of Dynamic Cancellation and Period Advancement

[0258] In this embodiment, when revoking one or more memberships, the group administrator only updates the group information and the public registry, without resetting global public parameters. The group administrator takes the current period group information, the public registry, and the set of members to be revoked as input, and executes a dynamic update algorithm to generate a new period identifier and new group information. This includes the updated accumulator state and an updated witness for still-valid members, allowing unrevoked members to continue using their existing private keys without rejoining. Simultaneously, the group administrator records the departure period of the revoked members in the public registry, allowing any verifier to determine whether a ciphertext must correspond to a "currently valid member" based on public information. After revocation, the new group information becomes the sole basis for subsequent encryption and verification. When encrypting, the sender downloads the latest group information and uses "the receiver is valid in the current period" as a necessary constraint for generating proof; therefore, ciphertext for revoked members either cannot generate verifiable proof of correctness or directly outputs a failure symbol. Thus, the revocation mechanism does not change public parameters or affect the availability of other members' keys, but it updates the public determination result of "valid members," thereby achieving fully dynamic member management.

[0259] Example 4: Implementation of Condition Tracking, Open, and Receiver Declaration of Denial

[0260] In this embodiment, when the sender sends a message to a designated recipient, it inputs an anonymous tag, an access policy predicate, and its witness, and outputs ciphertext and a publicly verifiable proof of correctness. During the encryption phase, the recipient's identifier and witness are incorporated into the policy calculation to obtain control bits, which determine the working state of the tags in the ciphertext: when the policy is not satisfied, a traceable tag is generated, allowing the opener to associate the ciphertext with the recipient under authorized conditions; when the policy is satisfied, an untraceable tag is generated, preventing any entity other than the recipient from establishing an identity association. The verifier can confirm the correct ciphertext format, the recipient's validity in the current period, and the policy constraints solely based on publicly available information and proof, thus preventing the generation of "verifiable ciphertext" for invalid members or unqualified objects. In case of disputes or audits, the opener performs an opening operation on the ciphertext: if it carries a traceable tag and meets the opening conditions, the recipient's identity is output; otherwise, a failure symbol is output, and anonymity is maintained. Furthermore, after obtaining the member joining record, the opener can restore the corresponding tracking trapdoor and verify any ciphertext to determine whether it was sent to that member. Meanwhile, with their own private key, recipients can generate publicly verifiable statements or denial evidence based on the ciphertext tags. Third parties can independently verify this, thus proving "whether the ciphertext was sent to them" without revealing their private key. This forms a closed-loop process covering encryption, verification, decryption, opening, tracking verification, and recipient self-verification, with each stage having clear inputs and outputs and verifiable conditions to support the feasibility and technical effectiveness of the solution.

[0261] Example 5: Application in an Enterprise's Internal Encrypted Email and Audit System

[0262] This embodiment deploys the invention within an enterprise's internal encrypted email and auditing system. The enterprise groups employee accounts as members, with the group administrator responsible for registration, dynamic addition and removal, and periodically publishing group information reflecting the status of active members. The email gateway acts as the verifier, performing verifiable format and policy checks on encrypted messages flowing through the system, achieving access control without decrypting the text or identifying the recipient. In daily operations, the sender generates encrypted messages according to enterprise policies, maintaining an anonymous appearance to reduce the risk of identity association exposure, while retaining necessary traceability under compliant authorization processes. In the event of compliance audits, misuse propagation, account hijacking, or internal threat investigations, the auditing authority can enable recipient-specific tracking for target members or perform open verification on individual encrypted messages, identifying and obtaining evidence only for relevant encrypted messages that meet the conditions, without affecting the anonymity and normal delivery of other members. During confidential projects or highly sensitive tasks, the system can automatically switch to a high-anonymity mode according to policies, making the corresponding encrypted messages statistically more anonymized, thereby suppressing inferences about the association between recipient identity and email activity, reducing the risk of being identified and tracked. To enhance dispute resolution capabilities, the system can also enable a declaration / denial mechanism: members can generate publicly verifiable evidence to prove whether they are the legitimate recipient of specific anonymous encrypted messages, which can be independently verified by third parties, providing support for liability determination, clarification of false reports, and audit evidence collection. This balances daily privacy protection with strong anonymity in confidential scenarios, enabling enterprises to achieve controllable and auditable investigation and accountability capabilities.

[0263] Evidence related to the technical effects obtained by the embodiments of the present invention:

[0264] 1. Formal definition of evidence

[0265] This invention provides a complete set of syntax and security requirements for “a privacy-enhanced, fully dynamic, traceable group encryption method and system”, including system initialization, member management, encryption and verification, authorized opening / tracking, and declaration / denial objectives, providing clear and verifiable criteria for judging the effectiveness of each technology.

[0266] 2. Evidence of the construction of core components

[0267] This invention introduces a controllable tracking and claim-based anonymous tagging system as a key foundational component, defines its syntax and security concepts and provides a specific construction, theoretically supporting two key effects: under authorized conditions, controlled tracking can be performed on encrypted text to obtain verifiable conclusions; users can generate publicly verifiable claims or denial evidence, which can be independently verified by third parties for dispute resolution and liability determination.

[0268] 3. Construction and security evidence

[0269] This invention provides a general construction for privacy-enhanced, fully dynamic, traceable group encryption and an instantiation scheme based on standard cryptographic components. It also proves that the general construction satisfies the defined security objectives, thereby demonstrating that the method and system of this invention can achieve the expected privacy enhancement and traceability functions within the same framework.

[0270] 4 Performance Analysis Evidence

[0271] This invention performs performance and complexity analysis on the instantiation and compares it with related solutions. Evaluation results are given from the dimensions of algorithm function coverage, key and ciphertext overhead and communication overhead, indicating that the method and system of this invention are feasible to deploy and can achieve the expected technical effects.

[0272] It should be noted that embodiments of the present invention can be implemented in hardware, software, or a combination of both. The hardware portion can be implemented using dedicated logic; the software portion can be stored in memory and executed by a suitable instruction execution system, such as a microprocessor or dedicated-design hardware. Those skilled in the art will understand that the above-described devices and methods can be implemented using computer-executable instructions and / or included in processor control code, for example, such code provided on a carrier medium such as a disk, CD, or DVD-ROM, a programmable memory such as read-only memory (firmware), or a data carrier such as an optical or electronic signal carrier. The devices and modules of the present invention can be implemented by hardware circuitry such as very large-scale integrated circuits or gate arrays, semiconductors such as logic chips, transistors, or programmable hardware devices such as field-programmable gate arrays, programmable logic devices, etc., or by software executed by various types of processors, or by a combination of the above-described hardware circuitry and software, such as firmware.

[0273] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any modifications, equivalent substitutions, and improvements made by those skilled in the art within the scope of the technology disclosed in the present invention, and within the spirit and principles of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A privacy-enhanced, fully dynamic, traceable group encryption method, characterized in that, Includes the following steps: Establish an anonymous labeling system that supports controlled tracking and verifiable claims; The group administrator generates and maintains the group public key, group information, and member validity status, and dynamically updates member additions and removals without resetting system parameters. The sender binds the recipient's identity information, member validity proof, and tracking conditions simultaneously during encryption, so that the ciphertext can be associated with the recipient by the opener when the tracking conditions are met, and remains anonymous when the tracking conditions are not met. The sender generates a publicly verifiable proof of correctness to prove that the ciphertext was indeed generated for the current valid group members and satisfies the predetermined access policy; The plaintext is decrypted by the recipient only if they are the intended recipient and the access policy is satisfied. The opener can restore the receiver's identity only if the tracking conditions are met; The recipient, with possession of its own key, generates publicly verifiable assertion or denial evidence to prove whether the ciphertext was sent to itself. When generating ciphertext, the receiver's identity information and the result of the access policy calculation are used as input to generate a control bit; when the control bit indicates that the access policy is not satisfied, the tag in the ciphertext is set to a traceable tag; when the control bit indicates that the access policy is satisfied, the tag in the ciphertext is set to an untraceable tag. This allows the opener to associate the recipient's identity only with traceable tags, and not with untraceable tags; The recipient generates assertion or denial evidence based on the tags in the anonymous ciphertext using their own key; The evidence can be independently verified by any third party to confirm whether the ciphertext is the legitimate ciphertext of the recipient; verifiable ownership confirmation is achieved without exposing the recipient's private key.

2. The method according to claim 1, characterized in that, The anonymous tagging system supports tag tracking and source declaration, enabling the same tag to simultaneously possess traceability and verifiable attribution.

3. The method according to claim 1, characterized in that, Group member revocation is achieved by updating group information and member witnesses, ensuring that revocation only affects the revoked member and does not affect the key validity of other members.

4. The method according to claim 1, characterized in that, The control bits are calculated jointly by the receiver identification information and the access policy witness.

5. The method according to claim 1, characterized in that, Traceable and untraceable tags maintain the same distribution in structure, making it impossible for third parties to distinguish whether tracking is enabled.

6. The method according to claim 1, characterized in that, Declarative evidence is used to prove that the tag was generated under the recipient's public key, while denial evidence is used to prove that the tag was not generated under the recipient's public key.

7. The method according to claim 1, characterized in that, Declaration and denial evidence are generated using non-interactive verifiable proofs, allowing the verifier to complete the verification without interacting with the recipient.

8. The method according to any one of claims 1 to 7, characterized in that, The permissions of the group administrator, the opener, and the receiver are independent of each other, making it impossible for any single entity to simultaneously perform decryption, tracking, and declaration operations.

Images