Multi-party secure computation systems, methods, devices, storage media, and program products

Abstract

One or more embodiments of the present specification provide a multi-party secure computing system, method, device, storage medium and program product. The multi-party secure computing system comprises a data holder, a data query party and N computing participants; the data holder splits a data table held by itself into N secret sub-tables and sends the N secret sub-tables to the N computing participants respectively; the computing participant extracts a secret sharing column of a target field to be sorted from the secret sub-table; based on the secret sharing column of the target field, the computing participant obtains a sorted secret sharing column in cooperation with other computing parties, and determines a secret shard of a permutation sequence number corresponding to each secret sharing value in the sorted secret sharing column; the data query party sends a query statement to the computing participant; the computing participant is also used for, if the query statement indicates querying the data table, rearranging the secret sub-table in cooperation with other computing participants according to the secret shard of the permutation sequence number corresponding to the target field, and executing the query based on the rearranged secret shard.

Description

Technical Field

[0001] This specification relates to the field of privacy computing technology, and in particular to a multi-party secure computing system, a multi-party secure computing method, an electronic device, a computer-readable storage medium, and a computer program product. Background Technology

[0002] In the field of data analysis and information processing, with the development of big data technology, the demand for collaborative computing among different data subjects is growing, especially in scenarios involving privacy-sensitive information, such as financial risk control, medical research, and government collaboration. To meet the needs of secure and compliant computing, Multi-Party Computation (MPC) technology has emerged.

[0003] Existing secure multi-party computation (MPC) systems typically allow multiple participants to collaborate on specific computational tasks without disclosing the original data of the data subjects. However, handling complex data query requests, especially those involving database operations such as sorting, filtering, joining, and aggregation, often involves comparing, judging, or grouping certain fields. These operations can be performed efficiently in traditional plaintext databases, but face significant challenges in an MPC environment.

[0004] Because the participants in the computation hold encrypted data, they cannot directly compare the size of any two data items or determine their order. Direct plaintext comparison or exchange would lead to data privacy breaches. Therefore, in an MPC environment, a dedicated secure sorting protocol (such as one based on comparison circuits or sorting networks) must be used to sort the data in an encrypted state. Traditional methods re-securely sort the data for each query, causing the sorting operation to become a performance bottleneck during the overall query execution. This is especially true when the data volume is large, queries are frequent, or the combinational logic is complex, significantly increasing computational resource consumption and severely limiting execution efficiency. Summary of the Invention

[0005] In view of the above, this specification provides one or more embodiments of a multi-party secure computing system, a multi-party secure computing method, an electronic device, a computer-readable storage medium, and a computer program product.

[0006] To achieve the above objectives, one or more embodiments of this specification provide the following technical solutions:

[0007] According to a first aspect of one or more embodiments of this specification, a multi-party secure computation system is proposed, including a data holder, a data queryer, and N computation participants, where N > 1;

[0008] The data holder is configured to split its own data table into N secret sub-tables according to a preset secret sharing algorithm, and send the N secret sub-tables to the N computing participants respectively; the table structure of the N secret sub-tables is the same as the table structure of the data table;

[0009] The computing participants are configured to receive and store the secret partition table, extract the secret shared column of the target field to be sorted from the secret partition table, and, based on the secret shared column of the target field, collaborate with other computing participants to execute a preset secure sorting algorithm to obtain the sorted secret shared column. Based on the sorted secret shared column, collaborate with other computing participants to determine the secret fragments that correspond one-to-one with the arrangement sequence number of each secret shared value in the sorted secret shared column.

[0010] The data querying party is used to send query statements to the computing participants;

[0011] The computational participants are further configured to, if the query statement indicates a query of the data table, rearrange the secret partition table in collaboration with other computational participants according to the secret partition of the arrangement number corresponding to the target field in the data table, to obtain a rearranged secret partition table; and, based on the rearranged secret partition table, collaboratively execute the query operation indicated by the query statement in collaboration with other computational participants.

[0012] According to a second aspect of the embodiments of this specification, a multi-party secure computation method is provided, applied to the computation participants described in the first aspect, the method comprising:

[0013] Receive and store a secret partition table sent by any data holder, and extract the secret shared column of the target field to be sorted from the secret partition table;

[0014] Based on the secret shared column of the target field, a preset secure sorting algorithm is executed in collaboration with other computing participants to obtain the sorted secret shared column;

[0015] Based on the sorted secret sharing column, secret fragments are determined in collaboration with other computing participants, with each secret sharing value in the sorted secret sharing column corresponding to a unique sequence number.

[0016] Receive a query statement sent by any data querying party. If the query statement indicates a query for the data table corresponding to the secret partition table, rearrange the secret partition table in collaboration with other computing participants according to the secret partition of the sorting number corresponding to the target field in the data table, and obtain the rearranged secret partition table.

[0017] Based on the rearranged secret partition table, the query operation indicated by the query statement is executed in collaboration with other computing participants.

[0018] According to a third aspect of the embodiments of this specification, an electronic device is provided, comprising:

[0019] processor;

[0020] Memory used to store processor-executable instructions;

[0021] Wherein, when the processor executes the executable instructions, it is used to implement the method described in the second aspect.

[0022] According to a fourth aspect of the embodiments of this specification, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps of the method described in the second aspect.

[0023] According to a fifth aspect of the embodiments of this specification, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the method described in the second aspect.

[0024] The technical solutions provided in the embodiments of this specification may include the following beneficial effects:

[0025] In the embodiments described in this specification, the computational participants can collaboratively perform a secure sorting operation on the target field that needs to be sorted in the data table during the data import phase or before the first query. The sorted data is then stored in encrypted form as a secret fragment containing the permutation numbers of the shared secret column, avoiding the need to repeatedly execute the computationally expensive encrypted sorting protocol for each query. In subsequent queries, when the query statement involves the already sorted target field, the computational participants can directly reuse the pre-generated secret fragment containing the permutation numbers of the target field to collaboratively perform an encrypted rearrangement of the secret table, generating a rearranged secret table. Based on this, they can then securely execute the subsequent query operations specified in the query statement.

[0026] This approach moves secure sorting operations forward to the data preprocessing stage, removing the high-cost encrypted sorting process from the query path and effectively reducing the computational and communication complexity of each query. Each query only requires a lightweight encrypted rearrangement operation based on secret sharding of permutation numbers, which can reduce query latency from the traditional near-logarithmic level to the linear level. Furthermore, all permutation numbers exist in the form of secret shards, ensuring that no field values, sorting order, or data distribution characteristics are leaked throughout the query process, fully meeting the privacy protection requirements of multi-party computation.

[0027] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this specification. Attached Figure Description

[0028] Figure 1 This is a schematic diagram of the architecture of a multi-party secure computing system provided in an exemplary embodiment.

[0029] Figure 2 This is an exemplary embodiment of a diagram illustrating the splitting of a data table into three secret sub-tables.

[0030] Figure 3 This is a schematic diagram of a connection operation provided in an exemplary embodiment.

[0031] Figure 4 This is another schematic diagram of the connection operation provided in an exemplary embodiment.

[0032] Figure 5 This is yet another schematic diagram of a connection operation provided in an exemplary embodiment.

[0033] Figure 6 This is a schematic diagram of an exemplary embodiment of updating the sequence number corresponding to the non-connected field in the first replicated secret table for the secret shard.

[0034] Figure 7 This is a flowchart of a multi-party secure computation method provided in an exemplary embodiment.

[0035] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an exemplary embodiment. Detailed Implementation

[0036] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

[0037] It should be noted that the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification in other embodiments. In some other embodiments, the methods may include more or fewer steps than described in this specification. Furthermore, a single step described in this specification may be broken down into multiple steps in other embodiments; and multiple steps described in this specification may be combined into a single step in other embodiments.

[0038] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this manual are all information and data authorized by the user or fully authorized by all parties. The collection, use and processing of related data shall comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals shall be provided for users to choose to authorize or refuse.

[0039] In recent years, secure multi-party computation (MPC) has enabled multiple data subjects to collaboratively execute complex queries on their respective private data, exposing only the final results and not revealing any intermediate information. This feature perfectly meets the needs of sectors such as banking, insurance, and healthcare to share insights while protecting customer privacy.

[0040] In an exemplary scenario, suppose several different institutions (such as insurance companies, hospitals, and banks) want to collaborate on analyzing data (insurance policies, medical records, bank balances) of the same group of customers, but they don't want to disclose their original data to each other. This is where "secure multi-party computation" (MPC) comes in: each institution "encrypts" its data, shards it, and sends it to several computational participants. The participants collaborate to calculate the query results, but they cannot see the original data. For example, consider the query to calculate the total medical expenses × insurance reimbursement ratio for patients with a balance ≥ 10,000, categorized by disease type. In a regular database, this query can be completed quickly (linear time). However, in MPC, to ensure the order is not leaked during join operations, a specialized secure sorting protocol (such as a protocol based on comparison circuits or sorting networks) must be used to sort the data in an encrypted state. Traditional methods re-securely sort the data for each query, causing the sorting operation to become a performance bottleneck during the overall query execution. This is especially true when the data volume is large, queries are frequent, or the combinational logic is complex, significantly increasing computational resource consumption and severely limiting execution efficiency.

[0041] Based on this, the embodiments of this specification provide a multi-party secure computation system that changes the "secure sorting" process from being performed for every query to being performed only once during the data import stage or before the first query. The sorting information is obtained and saved, and subsequent query processes can reuse the sorting information, thereby effectively reducing redundant calculations and communication and improving query efficiency.

[0042] Please see Figure 1 This specification provides a multi-party secure computation system, including a data holder, a data queryer, and N computation participants, where N > 1. The data holder can be at least one, and the computation participants can include at least two, for example... Figure 1As shown, there can be three computing participants to achieve secure three-party computation. These participants can come from different computing institutions or the same institution; this embodiment does not impose any restrictions on this. Each computing participant can include a physical server, a server cluster, or a virtual server, but is not limited to these.

[0043] The data holder is responsible for splitting its own data table into N secret sub-tables according to a preset secret sharing algorithm, and sending the N secret sub-tables to N computing participants respectively; the table structure of the N secret sub-tables is the same as the table structure of the data table.

[0044] It is understood that the embodiments in this specification do not impose any restrictions on the secret sharing algorithm, and specific choices can be made according to the actual application scenario. Under a general architecture, the data holder splits its own data table into N secret sub-tables, and sends the N secret sub-tables to N computing participants respectively. Each computing participant obtains at least one secret sub-table from the N secret sub-tables.

[0045] For example, please refer to Figure 2 The data table was split into three secret sub-tables, which were then distributed to the three computing participants.

[0046] In one possible implementation, the data holder, following a traditional secret sharing protocol, splits the original data into three distinct secret tables, distributing each table to a corresponding computational participant. Each participant receives only one secret table, and all computational operations are performed collaboratively with other parties based on their local share.

[0047] In another possible implementation, the data holder employs a Replicated Secret Sharing algorithm, where the data table is divided into multiple "shares" and distributed among multiple computational participants. The aim is to ensure that even if some computational participants fail or are attacked, the remaining participants can still recover the original information. Each computational participant receives two of the three secret tables; for example, participant 1 receives secret table 1 and secret table 2, participant 2 receives secret table 1 and secret table 3, and participant 3 receives secret table 2 and secret table 3. It is important to note that regardless of the secret sharing algorithm used, each computational participant maintains a consistent processing flow for each secret table it receives. Computational tasks such as encrypted sorting, join determination, secure comparison, and rearrangement are all performed collaboratively with other computational participants based on their local secret tables, without needing to access the complete original data. This ensures that the system fully complies with the privacy protection constraints of secure multi-party computation.

[0048] The phrase "the table structure of the N secret partitions is the same as the table structure of the original data table" means that the split secret partitions are completely identical to the original data table in terms of data organization, field definitions, and constraints, specifically including but not limited to:

[0049] (1) The number of fields is the same. The secret table contains the exact same fields (columns) as the original data table. For example, if the original table has three fields: "ID", "Name" and "Age", each secret table must also contain these three fields. No fields will be added or removed.

[0050] (2) Field types are the same. The data type (such as integer, string, date, etc.) and length constraints of each field are consistent with those of the original table. For example, if the "age" field in the original data table is an integer, the field in the secret table must also be an integer, and the value range (such as whether null is allowed, whether there is a default value, etc.) must be consistent.

[0051] (3) The primary key and index are the same. If the original data table has a primary key (such as "ID" as the primary key) or index, the definition of the primary key or index will also be retained in the secret partition table (although the actual data may be stored in partitions, the constraint rules still exist).

[0052] (4) Foreign keys and relationships are the same. If the original data table involves foreign key relationships (such as referencing fields from other tables), the definition of the foreign key fields will still be retained in the secret partition table to ensure that the data after partitioning can still be logically related to other tables.

[0053] (5) Field names must be identical. The name of the secret table can be customized (e.g., "Secret Table 1"), but the field names must be exactly the same as those of the original data table so that they can be aligned and processed according to the same fields in subsequent collaborative calculations.

[0054] (6) Each row of data (a row of data is a tuple) has the same format: Each row of data in the secret table is the same as the original data table, containing the values ​​of all fields (although the specific values ​​may be fragments of the original data or encrypted values).

[0055] It is understood that the embodiments in this specification do not impose any restrictions on the secret sharing algorithm, and existing secret sharing algorithms in related technologies can be directly applied.

[0056] For example, the data holder may also send the metadata of the data table to N computation participants. The metadata of the data table may include field names, comments (such as "User ID", "Transaction Amount", etc.), field types (such as integer, string, date), length limits (such as the "Mobile Number" field being an 11-character string), and constraint rules (such as primary key, NOT NULL, unique, etc.) to ensure that all computation participants have a consistent semantic understanding of the data.

[0057] The computational participants are used to receive and store metadata and secret partitions of the data tables. They can determine all target fields that need to be sorted based on the metadata in the data tables. For example, they can determine join fields, aggregation fields, projection fields, etc., based on the description information of each field in the metadata, and determine these fields as target fields that need to be sorted.

[0058] The calculation of participants is also used to extract the secret shared column of the target field that needs to be sorted from the secret partition table. For an example, please refer to... Figure 2 Assuming that field 3 is determined as the target field, and taking the example of each computing party holding one secret sub-table, computing participant 1 extracts the secret shared column of field 3 from secret sub-table 1, namely {g1, k1, l1}, computing participant 2 extracts the secret shared column of field 3 from secret sub-table 1, namely {g2, k2, l2}, and extracts the secret shared column of field 3 from secret sub-table 3, namely {g3, k3, l3}.

[0059] The computational participants are also used to collaboratively execute a pre-defined secure sorting algorithm based on the secret shared column of the target field, obtaining a sorted secret shared column. Specifically, N computational participants, based on this secure sorting algorithm, perform secure comparison operations on each secret shared value of the target field within the secret shared data structure. They collaboratively calculate the position of each secret shared value in the sorted result and perform a secure permutation operation based on this position, rearranging the corresponding secret shared values ​​to generate the sorted secret shared column. During the secure sorting process, each computational participant completes the collaborative computation without disclosing any input values, comparison results, or sorting order, ensuring complete privacy protection throughout the entire sorting operation. It is understandable that after secure sorting, the position of each secret shared value in the sorted secret shared column is naturally its sorting index.

[0060] The computational participants are also used to collaboratively determine, based on the sorted secret shared column, the secret slices that correspond one-to-one with the permutation numbers of each secret shared value in the sorted secret shared column, in collaboration with other computational participants.

[0061] In one possible implementation, the computational participants, specifically when acting as the primary computational participant, generate a unique permutation number corresponding one-to-one with each secret shared value in the sorted secret shared column after obtaining the sorted secret shared column. Based on a preset secret sharing algorithm, each permutation number is split into N secret fragments, one of which is retained, and the other N-1 secret fragments are sent to the other N-1 computational participants. In this embodiment, although the primary computational participant generates plaintext permutation numbers, each computational participant can only see its own secret fragment of the permutation number after the secret sharing processing, and cannot reconstruct the plaintext permutation number. Therefore, it can continue to be used in encrypted mode in subsequent query operations without revealing any sorting details. The primary computational participant centrally generates plaintext permutation numbers, uniformly splits them into secret fragments, and distributes them to each participant. This method is simple to operate, logically clear, and has low implementation overhead.

[0062] In another possible implementation, each computational participant, after obtaining the sorted secret shared column, generates a unique permutation number corresponding one-to-one with each secret shared value in the sorted secret shared column. Based on a preset secret sharing algorithm, each permutation number is split into N secret fragments, and a designated one of the N secret fragments is retained. In this embodiment, all computational participants know that "n values ​​need to be sorted" and also possess the sorted secret shared column. Therefore, each computational participant can independently generate a secret fragment of the permutation number, which can then be used in an encrypted state in subsequent query operations without revealing any sorting details. Each computational participant independently generates its own secret fragment of the sorted number locally, without relying on a master computational party or centralized operation. This is suitable for distributed environments without a trusted master party, and eliminates the need to transmit the secret fragment of the number between computational participants, reducing the system communication burden.

[0063] Both of the above implementation methods can ensure that the final generated permutation number is stored and used in a secret shared manner, avoiding the leakage of sensitive information such as sorting position or relative size in the sorting result.

[0064] The data query party is used to send query statements to the computation participants. For example, the metadata of a data table can be made public by the data holder to the data query party. The metadata includes field names, data types, index information, join relationships, etc. The data query party can construct a valid query statement based on the metadata, specifying the target field and query type (such as selection, projection, aggregation, etc.).

[0065] The computational participants are also used to receive query statements; if the query statement indicates a query on a data table, they collaborate with other computational participants to rearrange the secret partitions according to the secret partitions corresponding to the permutation numbers of the target fields in the data table, resulting in rearranged secret partitions; based on the rearranged secret partitions, they collaborate with other computational participants to execute the query operation indicated by the query statement.

[0066] Please see Figure 1 After each computing participant collaboratively completes the query operation indicated by the query statement, they generate a secret fragment of the query result and send the secret fragment of the query result to the data query party. The data query party then reconstructs the query result in plaintext form based on the received N secret fragments of the query result.

[0067] In this embodiment, the inventors discovered during the implementation of the multi-party secure computation system described in this specification that: in a three-party secure computation environment, traditional secure query schemes typically require performing a secure sorting operation for each query, with a computational complexity typically O(n*). ) or O( ), where n represents the number of tuples in the data table involved in the query, which leads to significant query latency and communication burden, especially affecting the real-time performance and scalability of the system in high-frequency access or large data volume scenarios.

[0068] This specification proposes a query preprocessing optimization mechanism in its embodiments. The secure sorting operation, which was originally repeated during the query phase, is moved to the data import phase or completed uniformly before the first query. The sorting result is cached in the form of secret shards of permutation numbers among the computation participants. In subsequent queries, the computation participants can directly reuse the generated secret shards of permutation numbers, requiring only one lightweight, rank-based encrypted rearrangement operation in collaboration with other computation participants to achieve an equivalent sorting effect without re-executing the high-overhead comparison and exchange protocol. Through this optimization, the sorting overhead in the query path is reduced from the traditional near-logarithmic complexity of O(n*n)... ) or O( The time complexity is significantly reduced to linear O(n), effectively compressing query latency and greatly improving the system's real-time response and high-frequency query processing capabilities. Furthermore, all permutation numbers exist in a secret sharding format, ensuring that no field values, sorting order, or data distribution characteristics are leaked throughout the query process, fully meeting the privacy protection requirements of multi-party computation. Specifically, during rearrangement and query operations, all sorting information, permutation numbers, and data tables remain secretly shared, without revealing the sorting order, field size relationships, or actual data content, guaranteeing the privacy of the entire query process.

[0069] The following provides illustrative examples of the execution process for different types of query operations:

[0070] (1) Selection operation: The selection operation is used to filter out a subset of tuples that meet the specified query conditions. Since the data table is distributed among multiple computing participants in a secret sharing manner, it is not possible to directly determine whether the tuple value meets the query conditions. Therefore, it needs to be executed collaboratively through a multi-party secure computing protocol.

[0071] In some embodiments, where the query operation indicated by the query statement includes a selection operation, the computational participants can, based on the query conditions of the selection operation, collaboratively determine with other computational participants whether each tuple in the secret partition table meets the query conditions, obtaining a secret partition of the determination result for each tuple. Then, based on the secret partitions of the determination results for each tuple, the computational participants, in collaboration with other computational participants, generate a secret partition with a marker field for each tuple. The marker field indicates whether a tuple is valid; the marker field corresponding to a tuple that meets the query conditions is a valid secret partition, and the marker field corresponding to a tuple that does not meet the query conditions is an invalid secret partition. In subsequent queries, invalid tuples can be masked or ignored using this marker field to ensure the accuracy of the query results.

[0072] To maintain the order and accuracy of the permutation numbers, the permutation numbers on the target field need to be updated after selection. The computational participants can collaboratively rearrange the secret table according to the secret fragments of the permutation numbers corresponding to the target field in the data table, obtaining a rearranged secret table. Then, based on the secret fragments of the labeled fields of each tuple in the rearranged secret table, they collaboratively move tuples with invalid labeled fields to the end of the rearranged secret table, retaining tuples with valid labeled fields at the beginning. Based on the moved rearranged secret table, they collaboratively determine the secret fragments of the permutation numbers corresponding one-to-one with specified tuples in the moved rearranged secret table. These specified tuples must include at least tuples with valid labeled fields. This operation ensures that the permutation numbers of tuples with valid labeled fields are compact (consecutive 1, 2, ..., m), retaining the correct sorting position and not containing invalid tuples filtered out by the selection operation, facilitating subsequent operations such as pagination and grouping.

[0073] In some scenarios, secret fragments with permutation numbers can be reassigned to tuples whose tag fields are invalid. This embodiment does not impose any restrictions on this.

[0074] (2) Projection operation. The projection operation refers to selecting certain specific columns (fields) from the data table and removing duplicates as the output result.

[0075] In some embodiments, where the query operation indicated by the query statement includes a projection operation and the target field includes the projection field specified by the projection operation, the computation participants can, in collaboration with other computation participants, rearrange the secret partitions according to the secret partitions of the arrangement number corresponding to the projection field in the data table, to obtain rearranged secret partitions arranged according to the projection field, such as sorting by the projection field value from smallest to largest. Since the sorting order is preprocessed, the rearrangement process only involves position adjustment, which is efficient and does not reveal the specific field value.

[0076] Next, the computational participants can collaboratively compare the projected field values ​​of each tuple in the rearranged secret partition with those of the previous tuple to generate secret fragments of the comparison results for each tuple. This process effectively removes duplicates. The comparison results regarding the equality of projected field values ​​between tuples are kept secret and not disclosed to any single party, thus preventing attacks. Based on these secret fragments of the comparison results, the computational participants can collaboratively generate secret fragments with marked fields for each tuple. These marked fields indicate whether a tuple is valid. Tuples with field values ​​different from the previous tuple have marked fields that are valid, while tuples with field values ​​the same as the previous tuple have marked fields that are invalid.

[0077] To maintain the continuity and accuracy of the arrangement numbers for the projection fields used subsequently, the arrangement numbers need to be reallocated. The computational participants, based on the secret fragments of the labeled fields of each tuple in the rearranged secret table, collaborate with other computational participants to move tuples with invalid labeled fields to the end of the rearranged secret table, while retaining tuples with valid labeled fields at the beginning. Based on the moved rearranged secret table, they collaborate with other computational participants to determine secret fragments with arrangement numbers corresponding one-to-one to specified tuples in the moved rearranged secret table. These specified tuples must include at least tuples with valid labeled fields. This results in a deduplicated secret table that maintains a consistent sorting structure, which can then participate in subsequent aggregation and other operations. In this embodiment, after filtering out duplicate tuples, the arrangement numbers are reallocated to ensure sorting accuracy, which is beneficial for the correctness and stability of subsequent related operations, such as pagination and window functions.

[0078] In some scenarios, secret fragments with permutation numbers can be reassigned to tuples whose tag fields are invalid. This embodiment does not impose any restrictions on this.

[0079] (3) Aggregation operations. Aggregation operations are used to summarize, calculate and statistically analyze a set of data during the query process to obtain a single result, such as calculating the average, summing, counting, etc.

[0080] In some embodiments, where the query operation indicated by the query statement includes an aggregation operation and the target field includes the aggregation field specified by the aggregation operation, the system can perform a secure aggregation process under a secret shared data structure.

[0081] The computation participants can collaborate with other computation participants to rearrange the secret partitions according to the secret partitions corresponding to the arrangement numbers of the aggregation fields in the data table, and obtain rearranged secret partitions arranged according to the aggregation fields. The rearrangement process is completed without revealing the field values ​​or order of the aggregation fields, which prepares for subsequent grouping and aggregation.

[0082] Next, the computational participants can collaborate with other participants to detect whether the aggregate field value of each tuple in the rearranged secret partition table is the same as the aggregate field value of its predecessor, generating secret partitions of the detection results for each tuple. Specifically, if the aggregate field value of a tuple is the same as the aggregate field value of its predecessor, the two belong to the same group; if the aggregate field value of a tuple is different from the aggregate field value of its predecessor, that tuple is the first tuple in the new group.

[0083] Based on the secret fragments generated from the detection results of each tuple, the system collaborates with other computational participants to perform the following operations: Grouping the tuples in the rearranged secret fragment table, with tuples having the same aggregation field value belonging to the same group; performing aggregation operations on the tuples within each group; and writing the aggregation result into the last tuple of each group in a secret-shared format. Simultaneously, it generates secret fragments with labeled fields for each tuple in the rearranged secret fragment table. The labeled fields indicate whether a tuple is valid; the labeled field corresponding to the last tuple in each group is a validly labeled secret fragment, while the labeled fields corresponding to the remaining tuples are invalidally labeled secret fragments. The entire aggregation process (grouping judgment, aggregation function calculation, and result labeling) is completed within the secret-shared structure, without exposing the original data, group boundaries, or aggregation values, effectively preventing information leakage.

[0084] To maintain the continuity of the sorting, computational participants can collaborate with other participants to move tuples with invalid tags to the end of the rearranged secret table, based on secret fragments of the labeled fields of each tuple in the rearranged secret table arranged according to the aggregation field, while retaining tuples with valid tags at the beginning. Based on the moved rearranged secret table, they can collaborate with other participants to determine secret fragments that correspond one-to-one with the permutation numbers of specified tuples in the moved rearranged secret table, where the specified tuples must include at least those with valid tags. By reassigning permutation numbers to secret fragments after aggregation, subsequent operations can maintain logical continuity, which is beneficial for applications such as pagination output and aggregation result display.

[0085] In some scenarios, secret fragments with permutation numbers can be reassigned to tuples whose tag fields are invalid. This embodiment does not impose any restrictions on this.

[0086] (4) Semi-join operation. A semi-join is a filtering join operation based on the join field. Its function is to return only the tuples in the left table (first data table) that can find the matching items in the right table (second data table), but without concatenating the fields in the right table.

[0087] In some embodiments, where the query operation indicated by the query statement includes a semi-join operation on two data tables and the target field includes the join field specified by the semi-join operation, the system can perform a secure semi-join procedure under a secret shared data structure.

[0088] The computing participants can determine a first rearranged secret table corresponding to the first data table in the two data tables and arranged according to the join field, and a second rearranged secret table corresponding to the second data table in the two data tables and arranged according to the join field, based on a similar rearrangement process as described above.

[0089] Next, the computational participants can collaborate with other participants to determine whether each tuple in the first rearranged secret table has a matching join field value in the second rearranged secret table, generating secret fragments of the matching results for each tuple in the first rearranged secret table. Based on these secret fragments, they collaborate with other participants to generate secret fragments of labeled fields for each tuple in the first rearranged secret table. Tuples with a "yes" match have labeled fields that are valid secret fragments, while tuples with a "no" match have labeled fields that are invalid secret fragments. During the semi-join process, all field values, matching results, and labeled states exist in the form of secret fragments, and no computational participant can independently infer the data content or join hit information.

[0090] To ensure a compact and sequential output structure after the query, the computation participants can collaborate with other participants to move tuples with invalid tags to the end of the first rearranged secret partition table, based on the secret partitions of the tag fields of each tuple in the first rearranged secret partition table, while retaining tuples with valid tags at the beginning. Based on the moved first rearranged secret partition table, they can collaborate with other participants to determine secret partitions with permutation numbers corresponding one-to-one to specified tuples in the moved first rearranged secret partition table, where the specified tuples must include at least those with valid tags. By reassigning secret partitions with permutation numbers to valid tuples, subsequent operations maintain logical sequential continuity. In some scenarios, tuples with invalid tags can also be reassigned secret partitions with permutation numbers; this embodiment does not impose any restrictions on this.

[0091] (5) Join operation. In plaintext databases, the join operation is used to combine tuple pairs from two tables whose join field values ​​are equal. In a secret sharing environment, field values ​​cannot be directly accessed for joining; therefore, a collaborative protocol must be used to implement the join process to ensure that data privacy is not compromised.

[0092] In some embodiments, where the query operation indicated by the query statement includes a join operation on two data tables and the target field includes the join field specified by the join operation, the system can perform a secure join procedure under a secret shared data structure.

[0093] The computing participants can determine a first rearranged secret table corresponding to the first data table in the two data tables, arranged according to the join field, and a second rearranged secret table corresponding to the second data table in the two data tables, also arranged according to the join field, based on a similar rearrangement process. This optimizes the access order for subsequent matching. For example, the first data table contains fields A and B, where the arrangement number for A is / A / and the arrangement number for B is / B / . Figure 3 The diagram shows the secret partition table corresponding to the first data table and the first rearranged secret partition table. The second data table contains fields B and C, where B corresponds to the permutation number / B / and C corresponds to the permutation number / C / . Figure 4 The second rearranged secret partition table corresponding to the second data table is shown. The two data tables are joined based on the join field B. It should be noted that, for ease of understanding, Figure 3 , Figure 4 , Figure 5 as well as Figure 6 The field values ​​and sequence numbers are represented in plaintext, but in actual applications, they exist in encrypted form.

[0094] Next, the computational participants can collaborate with other computational participants to count the number of tuples in the first rearranged secret table that match the join field values ​​in the second rearranged secret table, and to count the number of tuples in the second rearranged secret table that match the join field values ​​in the first rearranged secret table. This generates secret fragments representing the number of matches in the first rearranged secret table and secret fragments representing the number of matches in the second rearranged secret table. It should be noted that, for ease of understanding, Figure 3 and Figure 4 The number of copies (i.e., the number of matches) in the code is represented in plaintext, but in actual applications, the number of copies (i.e., the number of matches) exists in ciphertext.

[0095] Please see Figure 3The computational participants can collaborate with other computational participants to copy the tuples in the first rearranged secret table according to the corresponding number of matches based on the secret fragments of each tuple in the first rearranged secret table, thus obtaining the first copied secret table.

[0096] Please see Figure 4 The participants calculate the secret fragments based on the matching number of each tuple in the second rearranged secret table, and collaborate with other participants to copy the tuples in the second rearranged secret table according to the corresponding matching number, thus obtaining the second copied secret table.

[0097] After rearranging the secret partitions corresponding to the two data tables, the computational participants further collaborate with each other to count the number of join matches for each tuple and perform tuple replication accordingly. This is because, in traditional plaintext databases, join operations (such as equi-joins) are typically completed by concatenating tuples with equal join field values ​​one-to-one, requiring no additional processing. However, in multi-party secure computation scenarios, since each computational participant cannot directly observe the plaintext content of any data item, nor can they determine how many external tuples a particular tuple matches, it is impossible to dynamically generate all join results. To achieve join semantics equivalent to the plaintext environment, this system, through the aforementioned join match count and tuple replication process, prepares "matching pairs" that can be concatenated one-to-one in the physical structure. This pre-converts logical join relationships into structural sequential correspondences, allowing each computational participant to collaboratively complete secure join concatenation solely based on positional relationships, even without direct access to field values. Simultaneously, the number of matches is represented in the form of secret partitions to ensure that the statistical results do not reveal the true join distribution.

[0098] Next, please refer to Figure 4 The computational participants align the second replicated secret table so that the sorting order of tuples in the aligned second replicated secret table is consistent with the sorting order of tuples in the first replicated secret table. During the alignment process, the computational participants collaboratively perform the following operations with other computational participants: sort the second replicated secret table according to the values ​​of the sorting field, for example... Figure 4 First, sort the data according to field B, in the order b1→b2→b3; if there are multiple tuples with the same sorting field value, such as... Figure 4 In the table, b1 corresponds to 6 tuples. Then, a second sorting is performed according to the copying order of each tuple in the multiple tuples. In the second sorting, the tuple with the earlier copying order also has the earlier sorting order, thus obtaining the aligned second copy secret table.

[0099] The reason for alignment is that in traditional plaintext database systems, join operations can be implemented by directly comparing join fields and dynamically concatenating matching tuples. However, in multi-party secure computation systems, since all field values ​​are stored in a secret shared format, the computation participants cannot directly know the join field value of any tuple, nor can they logically "jump" to a specified tuple position for matching and concatenation. To achieve secure tuple concatenation, a position alignment method is adopted. The two replicated secret shared data tables are sorted according to their join field values, and if the join field values ​​are the same, they are further sorted according to the copying order of each tuple during the copying process. This double sorting operation ensures that there is a join field matching relationship between tuples at corresponding positions in the two tables. Through this alignment, the system can directly concatenate tuples from the two tables one by one in sequence without revealing the join field values ​​and join matching relationships, thereby completing the join operation securely and efficiently, avoiding errors in results or privacy leaks caused by misaligned concatenation.

[0100] The computational participants are also used to, for the first replicated secret partition, collaborate with other computational participants to determine the secret fragment of each tuple in the first replicated secret partition, whose permutation number corresponds to the sorting field; and, for the aligned second replicated secret partition, collaborate with other computational participants to determine the secret fragment of each tuple in the aligned second replicated secret partition, whose permutation number corresponds to the sorting field. (Please refer to...) Figure 3 and Figure 4 , Figure 3 This shows the sorting index of each tuple in the first replicated secret table, corresponding to the sorting field. Figure 4 The diagram shows the tuples in the sort field of the aligned second copy secret table.

[0101] Finally, please see Figure 5 The computing participants collaborate with other computing participants to splice the first replicated secret table and the aligned second replicated secret table, completing the connection operation while ensuring privacy and security throughout the data processing process.

[0102] For example, when the target fields involved in the first data table include not only the join fields but also at least one non-join field, in order to ensure the correctness and availability of the sorting information of the non-join field in subsequent operations, the system also needs to update the sorting sequence number corresponding to the non-join field when performing the join operation. In a plaintext database, the order of the non-join fields can directly follow the natural order of the join result. However, in a secret sharing environment, because the join operation requires copying, rearranging, and aligning tuples, the original sorting information of the non-join fields will be destroyed or invalidated. Therefore, if subsequent operations such as sorting, projection, deduplication, and aggregation based on the non-join field are involved, its corresponding sorting sequence number must be recalculated. Continuing with the example above, the first data table also includes a non-join field A, and the second data table also includes a non-join field C, requiring corresponding updates to their sorting sequence numbers.

[0103] If the target fields involved in the first data table also include non-join fields, please refer to [link / reference]. Figure 6 The computational participants determine a third-order secret partition corresponding to the first data table and arranged according to the non-join fields. Based on the third-order secret partition, they collaboratively perform update operations with other computational participants to update the secret shards of the permutation numbers corresponding to the non-join fields in the first replicated secret partition. Because in the first replicated secret partition, after tuple replication, since one original tuple may correspond to multiple new tuples, consecutive permutation numbers must be assigned to these replicated tuples to avoid permutation number conflicts or omissions.

[0104] The update operation includes: counting the number of times each tuple in the third-reordered secret partition is copied in the first-replicated secret partition; tuples not involved in the join have a copy count of zero; based on the copy count of each tuple in the third-reordered secret partition, calculating the initial sort number of each tuple with a non-zero copy count, the first tuple with a non-zero copy count has an initial sort number of one as the secret partition, and the initial sort numbers of other tuples are obtained by performing a prefix summation on the copy count and then adding one, such as... Figure 6 The initial sort index of the second tuple {a1, b2} is the result of 2 plus 1, which is the number of times the previous tuple {a1, b1} was copied. Figure 6The initial sorting index of the third tuple {a2, b1} is the sum of the replication counts of the first two tuples (3 plus 1), and so on. Each tuple is replicated based on its replication count in the third-reordered secret table, forming the third-replicated secret table. In this table, each tuple is traversed sequentially, and the non-connected field value of the current tuple is compared with the non-connected field value of the previous tuple. If the non-connected field values ​​are the same, the sorting index of the current tuple is set to the previous tuple's sorting index plus one; otherwise, it remains unchanged. In this embodiment, the prefix sum of replication counts is used as the initial sorting index, combined with an ordered incrementing strategy after determining if field values ​​are the same, ensuring the new sorting index has continuity, monotonicity, and distinguishability for repeating tuples. The updated sorting index information is represented by secret fragments in the secret sharing structure, without disclosing any field values, repeating relationships, or tuple distribution information, ensuring full privacy protection. Next, please refer to... Figure 6 After traversing all tuples in the third replicated secret table to determine the secret fragment corresponding to the permutation number of each tuple, the third replicated secret table is rearranged according to the join field B to obtain the first replicated secret table. In the first replicated secret table, the permutation order of the non-join field A is also determined.

[0105] Similarly, if the target fields involved in the second data table also include non-join fields, the computation participants determine the fourth rearranged secret partition table corresponding to the second data table and arranged according to the non-join fields. Based on the fourth rearranged secret partition table, they cooperate with other computation participants to perform update operations to update the secret partition of the arrangement number corresponding to the non-join fields in the second replicated data partition table.

[0106] The update operation includes: counting the number of times each tuple in the fourth rearranged secret partition is copied in the second replicated secret partition; tuples not involved in the join have a copy count of zero; calculating the initial sort number of each tuple based on its copy count in the fourth rearranged secret partition; the first tuple with a non-zero copy count has an initial sort number of one as its secret partition; the initial sort numbers of other tuples are obtained by prefix summing of their copy counts and adding one; copying each tuple based on its copy count in the fourth rearranged secret partition to form the fourth replicated secret partition; traversing each tuple in the fourth replicated secret partition and comparing the non-join field value of the current tuple with the non-join field value of the previous tuple; if the non-join field values ​​of the two tuples are the same, setting the sort number of the current tuple to the sort number of the previous tuple plus one; otherwise, keeping the sort number of the current tuple unchanged.

[0107] The various technical features in the above embodiments can be combined arbitrarily, as long as there is no conflict or contradiction between the combinations of features. However, due to space limitations, they are not described one by one. Therefore, the arbitrary combination of various technical features in the above embodiments is also within the scope of this specification.

[0108] In some embodiments, please refer to Figure 7 This specification also provides a multi-party secure computation method applicable to any of the computation participants described above. The method includes:

[0109] In S701, a secret partition table sent by any data holder is received and stored, and a secret shared column of the target field to be sorted is extracted from the secret partition table.

[0110] In S702, based on the secret shared column of the target field, a preset secure sorting algorithm is executed in collaboration with other computing participants to obtain the sorted secret shared column.

[0111] In S703, based on the sorted secret shared column, secret fragments are determined in collaboration with other computing participants, and the permutation number corresponding one-to-one with each secret shared value in the sorted secret shared column is determined.

[0112] In S704, a query statement sent by any data query party is received. If the query statement indicates a query for the data table corresponding to the secret partition table, the secret partition table is rearranged in collaboration with other computing participants according to the secret partition table with the sorting number corresponding to the target field. This results in a rearranged secret partition table.

[0113] In S705, based on the rearranged secret partitioning, the query operation indicated by the query statement is executed in collaboration with other computing participants.

[0114] In one implementation, based on the sorted secret shared column, the parties collaborate with other computing participants to determine the secret fragments, which correspond one-to-one with the permutation numbers of each secret shared value in the sorted secret shared column. This includes: when acting as the main computing participant, after obtaining the sorted secret shared column, generating unique permutation numbers that correspond one-to-one with each secret shared value in the sorted secret shared column; splitting each permutation number into N secret fragments based on a preset secret sharing algorithm, retaining one secret fragment, and sending the other N-1 secret fragments to the other N-1 computing participants respectively.

[0115] In one implementation, the method further includes: receiving metadata of the data table sent by a data holder, and determining the target field based on the metadata in the data table.

[0116] In one implementation, the method further includes: when the query operation indicated by the query statement includes a selection operation, based on the query conditions of the selection operation, collaboratively with other computing participants to determine whether each tuple in the secret partition table meets the query conditions, and obtain a secret partition of the determination result for each tuple; based on the secret partition of the determination result for each tuple, collaboratively with other computing participants to generate a secret partition with a tag field for each tuple; wherein the tag field is used to indicate whether the tuple is valid, the tag field corresponding to the tuple that meets the query conditions is a secret partition with a valid tag, and the tag field corresponding to the tuple that does not meet the query conditions is a secret partition with an invalid tag.

[0117] In one implementation, the step of collaboratively executing a query operation indicated by a query statement based on a rearranged secret partition includes: if the query operation indicated by the query statement includes a projection operation and the target field includes a projection field specified by the projection operation, determining a rearranged secret partition arranged according to the projection field, collaboratively comparing with other computational participants whether the projection field values ​​of each tuple in the rearranged secret partition are the same as the projection field values ​​of its predecessor, and generating secret partitions of the comparison results for each tuple; based on the secret partitions of the comparison results for each tuple, collaboratively with other computational participants generating secret partitions of labeled fields for each tuple; wherein the labeled fields are used to indicate whether a tuple is valid, and the labeled fields corresponding to tuples whose field values ​​are different from those of the predecessor are marked as valid secret partitions, and the labeled fields corresponding to tuples whose field values ​​are the same as those of the predecessor are marked as invalid secret partitions.

[0118] In one implementation, the step of collaboratively executing a query operation indicated by a query statement based on a rearranged secret partition includes: when the query operation indicated by the query statement includes an aggregation operation and the target field includes an aggregation field specified by the aggregation operation, determining a rearranged secret partition arranged according to the aggregation field, collaboratively detecting with other computing participants whether the aggregation field value of each tuple in the rearranged secret partition is the same as the aggregation field value of its predecessor, and generating a secret partition of the detection result for each tuple; based on the secret partition of the detection result for each tuple, collaboratively performing the following operations with other computing participants: performing a grouping operation on the tuples in the rearranged secret partition, tuples with the same aggregation field value belonging to the same group, and performing the aggregation operation on the tuples within each group, writing the aggregation result into the last tuple in the group, and simultaneously generating a secret partition with a marker field for each tuple in the rearranged secret partition; wherein the marker field is used to indicate whether the tuple is valid, the marker field corresponding to the last tuple in each group is a valid marked secret partition, and the marker fields corresponding to the remaining tuples are invalid marked secret partitions.

[0119] In one implementation, the method further includes: based on the secret fragments of the labeled fields of each tuple in the rearranged secret partition table, cooperating with other computational participants to move tuples with invalid labeled fields to the end of the rearranged secret partition table, and retaining tuples with valid labeled fields at the beginning of the rearranged secret partition table; based on the moved rearranged secret partition table, cooperating with other computational participants to determine secret fragments with permutation numbers corresponding one-to-one with specified tuples in the moved rearranged secret partition table, wherein the specified tuples include at least tuples with valid labeled fields.

[0120] In one implementation, the step of collaboratively executing a query operation indicated by a query statement based on a rearranged secret partition includes: determining a first rearranged secret partition corresponding to a first data table in the two data tables and arranged according to the join field, and determining a second rearranged secret partition corresponding to a second data table in the two data tables and arranged according to the join field; collaboratively determining with other computational participants whether each tuple in the first rearranged secret partition has a matching join field value in the second rearranged secret partition; generating a secret partition of the matching results of each tuple in the first rearranged secret partition; and collaboratively generating a secret partition of a labeled field for each tuple in the first rearranged secret partition based on the secret partition of the matching results of each tuple in the first rearranged secret partition, wherein the labeled field corresponding to a tuple with a "yes" matching result is a validly labeled secret partition, and the labeled field corresponding to a tuple with a "no" matching result is an invalidly labeled secret partition.

[0121] In one implementation, the method further includes: based on the secret fragments of the labeled fields of each tuple in the first rearranged secret partition table, cooperating with other computational participants to move tuples with invalid labeled fields to the end of the first rearranged secret partition table, and retaining tuples with valid labeled fields at the beginning of the first rearranged secret partition table; based on the moved first rearranged secret partition table, cooperating with other computational participants to determine secret fragments with permutation numbers corresponding one-to-one with specified tuples in the moved first rearranged secret partition table, wherein the specified tuples include at least tuples with valid labeled fields.

[0122] In one implementation, the step of collaboratively executing a query operation indicated by a query statement based on a rearranged secret partition, in collaboration with other computational participants, includes: if the query operation indicated by the query statement includes a join operation on two data tables, and the target field includes a join field specified by the join operation, determining a first rearranged secret partition corresponding to a first data table among the two data tables and arranged according to the join field; and determining a second rearranged secret partition corresponding to a second data table among the two data tables and arranged according to the join field; collaboratively with other computational participants, counting the number of tuples in the first rearranged secret partition whose join field values ​​match in the second rearranged secret partition, and counting the number of tuples in the second rearranged secret partition whose join field values ​​match in the first rearranged secret partition, generating a sequence of tuples in the first rearranged secret partition. The first and second rearranged secret tables are prepared by: a secret partition of the matching number of each tuple; a secret partition of the matching number of each tuple in the first rearranged secret table; a first replicated secret table, in collaboration with other computational participants, copying the tuples in the first rearranged secret table according to the corresponding matching number based on the secret partition of the matching number of each tuple in the second rearranged secret table; a second replicated secret table, in collaboration with other computational participants, copying the tuples in the second rearranged secret table according to the corresponding matching number based on the secret partition of the matching number of each tuple in the second rearranged secret table; and aligning the second replicated secret table so that the sorting order of each tuple in the aligned second replicated secret table is consistent with the sorting order of each tuple in the first replicated secret table; and concatenating the first replicated secret table and the aligned second replicated secret table in collaboration with other computational participants.

[0123] In one implementation, aligning the second replicated secret table includes: collaborating with other computational participants to perform the following operations: sorting the second replicated secret table first according to the field value of the sorting field; if there are multiple tuples with the same sorting field value, further sorting them second according to the replication order of each tuple in the multiple tuples to obtain the aligned second replicated secret table.

[0124] In one implementation, the method further includes: for the first replicated secret partition, collaborating with other computational participants to determine the secret partition of each tuple in the first replicated secret partition, which is associated with the sorting field; and for the aligned second replicated secret partition, collaborating with other computational participants to determine the secret partition of each tuple in the aligned second replicated secret partition, which is associated with the sorting field.

[0125] In one implementation, the method further includes: when the target fields involved in the first data table also include non-join fields, determining a third-order secret partition corresponding to the first data table and arranged according to the non-join fields; and, based on the third-order secret partition, collaboratively performing an update operation with other computational participants to update the secret fragments of the permutation numbers corresponding to the non-join fields in the first replicated secret partition; wherein the update operation includes: counting the number of times each tuple in the third-order secret partition is copied in the first replicated secret partition, with the number of copies of tuples not involved in the join being zero; and calculating the replication index based on the number of copies of each tuple in the third-order secret partition. The initial sorting index of each tuple with a non-zero replication count is determined. The first tuple with a non-zero replication count is assigned an initial sorting index of 1 as the secret partition. The initial sorting index of other tuples is obtained by prefixing and incrementing the replication count by one. Based on the replication count of each tuple in the third rearranged secret partition, each tuple is replicated to form a third replicated secret partition. In the third replicated secret partition, each tuple is traversed sequentially, and the non-connection field value of the current tuple is compared with the non-connection field value of the previous tuple. If the non-connection field values ​​of the two tuples are the same, the sorting index of the current tuple is set to the sorting index of the previous tuple plus one; if they are different, the sorting index of the current tuple remains unchanged.

[0126] In one implementation, the method further includes: if the target fields involved in the second data table also include non-join fields, determining a fourth rearranged secret partition corresponding to the second data table and arranged according to the non-join fields; and, based on the fourth rearranged secret partition, collaboratively performing an update operation with other computational participants to update the secret shards of the arrangement numbers corresponding to the non-join fields in the second replicated data partition; wherein the update operation includes: counting the number of times each tuple in the fourth rearranged secret partition is copied in the second replicated secret partition, with the number of copies of tuples not involved in the join being zero; and calculating based on the number of copies of each tuple in the fourth rearranged secret partition. The initial sorting index of each tuple with a non-zero replication count is determined. The first tuple with a non-zero replication count is assigned an initial sorting index of 1 as its secret partition. The initial sorting indexes of other tuples are obtained by prefixing and incrementing the replication counts. Based on the replication counts of each tuple in the fourth rearranged secret partition, each tuple is replicated to form the fourth replicated secret partition. In the fourth replicated secret partition, each tuple is traversed sequentially, and the non-join field value of the current tuple is compared with the non-join field value of the previous tuple. If the non-join field values ​​of the two tuples are the same, the sorting index of the current tuple is set to the sorting index of the previous tuple plus one. If they are not the same, the sorting index of the current tuple remains unchanged.

[0127] In some embodiments, this specification also provides an electronic device, including: a processor; a memory for storing processor-executable instructions; wherein the processor implements the method described in any one of the above embodiments by executing the executable instructions.

[0128] Figure 8 This is a schematic structural diagram of a device provided in an exemplary embodiment. Please refer to... Figure 8 At the hardware level, the device includes a processor 802, an internal bus 804, a network interface 806, memory 808, and non-volatile memory 810, and may also include other hardware required for its functions. One or more embodiments of this specification can be implemented in software, for example, the processor 802 reads the corresponding computer program from the non-volatile memory 810 into memory 808 and then runs it. Of course, besides software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution entity of the following processing flow is not limited to individual logic units, but can also be hardware or logic devices.

[0129] In some embodiments, the multi-party secure computing device can be applied to, for example... Figure 7 The device shown is used to implement the technical solution described in this specification. The multi-party secure computing device may include:

[0130] The data receiving and extraction module is used to receive and store secret partitions sent by any data holder, and extract the secret shared columns of the target fields that need to be sorted from the secret partitions.

[0131] The secure sorting module is used to collaboratively execute a preset secure sorting algorithm with other computing participants based on the secret shared column of the target field to obtain the sorted secret shared column.

[0132] The permutation number generation module is used to collaboratively determine, with other computing participants, the permutation number that corresponds one-to-one with each secret shared value in the sorted secret shared column.

[0133] The query module is used to receive query statements sent by any data query party. If the query statement indicates that the query is for the data table corresponding to the secret partition table, the module will rearrange the secret partition table in collaboration with other computing participants according to the secret partition table with the sorting number corresponding to the target field.

[0134] The query module is also used to collaboratively execute query operations indicated by query statements with other computing participants based on the rearranged secret partitions.

[0135] The specific implementation process of the functions and roles of each module in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0136] Based on the same concept as the methods described above, this specification also provides an electronic device, including: a processor; a memory for storing processor-executable instructions; wherein the processor performs the steps of the method as described in any of the above embodiments by executing the executable instructions.

[0137] Based on the same concept as the methods described above, this specification also provides a computer-readable storage medium having computer instructions stored thereon that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

[0138] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0139] Based on the same concept as the methods described above, this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

[0140] The above description is merely a preferred embodiment of one or more embodiments of this specification and is not intended to limit the scope of one or more embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of one or more embodiments of this specification should be included within the protection scope of one or more embodiments of this specification.

Claims

1. A multi-party secure computation system, comprising a data holder, a data queryer, and N computation participants, where N > 1; The data holder is configured to split its own data table into N secret sub-tables according to a preset secret sharing algorithm, and send the N secret sub-tables to the N computing participants respectively; the table structure of the N secret sub-tables is the same as the table structure of the data table; The computational participants are configured to receive and store the secret partition table; before executing the first query against the secret partition table, extract the secret shared column of the target field to be sorted from the secret partition table; based on the secret shared column of the target field, collaborate with other computational participants to execute a preset secure sorting algorithm to obtain the sorted secret shared column; based on the sorted secret shared column, collaborate with other computational participants to determine the secret fragments of the permutation number corresponding one-to-one with each secret shared value in the sorted secret shared column, and store the secret fragments of the permutation number corresponding one-to-one with each secret shared value in the sorted secret shared column; The data querying party is used to send query statements to the computing participants; The computational participants are further configured to, if the query statement indicates a query of the data table, rearrange the secret partition table in collaboration with other computational participants according to the secret partition of the arrangement number corresponding to the target field in the data table, to obtain a rearranged secret partition table; and, based on the rearranged secret partition table, collaboratively execute the query operation indicated by the query statement in collaboration with other computational participants.

2. In the system according to claim 1, the computing participant is specifically used, when acting as the main computing participant, to generate a unique permutation number corresponding one-to-one with each secret shared value in the sorted secret shared column after obtaining the sorted secret shared column; and to split each of the permutation numbers into N secret fragments based on a preset secret sharing algorithm, retaining one secret fragment and sending the other N-1 secret fragments to the other N-1 computing participants respectively.

3. In the system according to claim 1, the data holder is further configured to send the metadata of the data table to the N computing participants; The computational participants are also used to determine the target field based on the metadata in the data table.

4. The system according to claim 1, wherein the computing participant is further configured to: When the query operation indicated by the query statement includes a selection operation, based on the query conditions of the selection operation, the parties involved in the computation collaborate to determine whether each tuple in the secret partition table meets the query conditions, and obtain the secret partition of the judgment result of each tuple. Based on the judgment results of each tuple, a secret fragment is generated for each tuple in collaboration with other computational participants, along with a secret fragment containing a labeled field; wherein, The tag field is used to indicate whether a tuple is valid. Tuples that meet the query conditions are marked as valid secret shards, while tuples that do not meet the query conditions are marked as invalid secret shards.

5. The system according to claim 1, wherein the computing participant is specifically used for: If the query operation indicated by the query statement includes a projection operation and the target field includes the projection field specified by the projection operation, determine the rearranged secret partition table arranged according to the projection field, and compare with other computing participants whether the projection field value of each tuple in the rearranged secret partition table is the same as the projection field value of its predecessor, and generate a secret partition of the comparison result of each tuple. Based on the comparison results of the tuples, secret fragments of labeled fields are generated collaboratively with other computational participants to create secret fragments for each tuple; wherein, The tag field is used to indicate whether a tuple is valid. Tuples whose tag field values ​​are different from those of the previous tuple are secret fragments with valid tags, while tuples whose tag field values ​​are the same as those of the previous tuple are secret fragments with invalid tags.

6. The system according to claim 1, wherein the computing participant is specifically used for: If the query operation indicated by the query statement includes an aggregation operation and the target field includes the aggregation field specified by the aggregation operation, determine the rearranged secret partition table arranged according to the aggregation field, and cooperate with other computing participants to detect whether the aggregation field value of each tuple in the rearranged secret partition table is the same as the aggregation field value of its predecessor, and generate a secret fragment of the detection result of each tuple. Based on the secret fragments generated from the detection results of each tuple, the following operations are performed in collaboration with other computational participants: a grouping operation is performed on the tuples in the rearranged secret partition table; tuples with the same aggregation field value belong to the same group; the aggregation operation is performed on the tuples within each group; the aggregation result is written into the last tuple in the group; and a secret fragment with a labeled field is generated for each tuple in the rearranged secret partition table. The tag field is used to indicate whether a tuple is valid. The tag field corresponding to the last tuple in each group is a secret fragment with a valid tag, and the tag fields corresponding to the remaining tuples are secret fragments with invalid tags.

7. The system according to any one of claims 4 to 6, wherein the computing participant is further configured to: Based on the secret fragments of the labeled fields of each tuple in the rearranged secret partition table, tuples with invalid labeled fields are moved to the end of the rearranged secret partition table in cooperation with other computation participants, while tuples with valid labeled fields are kept at the beginning of the rearranged secret partition table. Based on the rearranged secret partition table after the move, secret fragments are determined in collaboration with other computational participants, with each fragment corresponding to a specified tuple in the rearranged secret partition table. The specified tuple includes at least tuples with a valid tag field.

8. The system according to claim 1, wherein the computing participant is specifically used for: When the query operation indicated by the query statement includes a semi-join operation on two data tables, and the target field includes the join field specified by the semi-join operation, a first rearranged secret partition table corresponding to the first data table in the two data tables and arranged according to the join field is determined, and a second rearranged secret partition table corresponding to the second data table in the two data tables and arranged according to the join field is determined. In collaboration with other computing participants, it is determined whether there are tuples in the first rearranged secret partition table that match the join field value in the second rearranged secret partition table, and a secret fragment of the matching result of each tuple in the first rearranged secret partition table is generated. Based on the secret fragments of the matching results of each tuple in the first rearranged secret partition table, secret fragments with labeled fields are generated collaboratively with other computational participants for each tuple in the first rearranged secret partition table, wherein, The tag field corresponding to a tuple with a matching result of "yes" is a secret shard with a valid tag, and the tag field corresponding to a tuple with a matching result of "no" is a secret shard with an invalid tag.

9. The system according to claim 8, wherein the computing participant is further configured to: Based on the secret fragments of the labeled fields of each tuple in the first rearranged secret partition table, tuples with invalid labeled fields are moved to the end of the first rearranged secret partition table in collaboration with other computation participants, while tuples with valid labeled fields are kept at the beginning of the first rearranged secret partition table. Based on the first rearranged secret partition table after the move, secret partitions with permutation numbers corresponding one-to-one with specified tuples in the first rearranged secret partition table are determined in collaboration with other computational participants. The specified tuples include at least tuples with valid flag fields.

10. The system according to claim 1, wherein the computing participant is specifically used for: If the query operation indicated by the query statement includes a join operation on two data tables, and the target field includes the join field specified by the join operation, a first rearranged secret table corresponding to the first data table in the two data tables and arranged according to the join field is determined, and a second rearranged secret table corresponding to the second data table in the two data tables and arranged according to the join field is determined. In collaboration with other computing participants, the number of tuples in the first rearranged secret table that have join field values ​​matching in the second rearranged secret table is counted, and the number of tuples in the second rearranged secret table that have join field values ​​matching in the first rearranged secret table is counted. Secret fragments with matching numbers of each tuple in the first rearranged secret table and secret fragments with matching numbers of each tuple in the second rearranged secret table are generated. Based on the secret fragments representing the number of matches for each tuple in the first rearranged secret partition table, the tuples in the first rearranged secret partition table are copied in collaboration with other computational participants according to the corresponding number of matches, resulting in a first copied secret partition table; and, Based on the secret fragments of the matching number of each tuple in the second rearranged secret partition table, the tuples in the second rearranged secret partition table are copied in collaboration with other computing participants according to the corresponding matching number to obtain a second copied secret partition table. The second copied secret partition table is then aligned so that the sorting order of each tuple in the aligned second copied secret partition table is consistent with the sorting order of each tuple in the first copied secret partition table. In collaboration with other computational participants, the first replicated secret table and the aligned second replicated secret table are spliced ​​together.

11. The system according to claim 10, wherein the computing participant is specifically used for: During the alignment process of the second replicated secret table, the following operations are performed in collaboration with other computation participants: the second replicated secret table is sorted first according to the field value of the sorting field; if there are multiple tuples with the same sorting field value, it is further sorted secondly according to the replication order of each tuple in the multiple tuples to obtain the aligned second replicated secret table.

12. The system of claim 10, wherein the computing participant is further configured to: For the first replicated secret partition table, in collaboration with other computational participants, the secret partition table is determined by assigning the permutation number corresponding to the sorting field to each tuple in the first replicated secret partition table; and... For the aligned second replicated secret table, the secret slices of each tuple in the aligned second replicated secret table, with the sorting field corresponding to the arrangement number, are determined in collaboration with other computation participants.

13. The system of claim 10, wherein the computing participant is further configured to: If the target fields involved in the first data table also include non-connected fields, determine the third rearranged secret partition table corresponding to the first data table and arranged according to the non-connected fields. Based on the third rearranged secret partition table, perform an update operation in collaboration with other computing participants to update the secret partition of the arrangement number corresponding to the non-connected fields in the first replicated secret partition table. in, The update operation includes: counting the number of times each tuple in the third rearranged secret partition table is copied in the first replicated secret partition table, with the number of copies of tuples not involved in the join being zero; calculating the initial sort number of each tuple with a non-zero copy number based on the copy number of each tuple in the third rearranged secret partition table, with the initial sort number of the first tuple with a non-zero copy number being the secret partition with an initial sort number of one, and the initial sort numbers of other tuples being obtained by prefix summation of the copy number followed by one; copying each tuple based on the copy number of each tuple in the third rearranged secret partition table to form the third replicated secret partition table; traversing each tuple sequentially in the third replicated secret partition table, and comparing the non-join field value of the current tuple with the non-join field value of the previous tuple; if the non-join field values ​​of the two tuples are the same, setting the sort number of the current tuple to the sort number of the previous tuple plus one; if they are different, keeping the sort number of the current tuple unchanged.

14. The system of claim 10, wherein the computing participant is further configured to: If the target fields involved in the second data table also include non-connected fields, determine the fourth rearranged secret partition table corresponding to the second data table and arranged according to the non-connected fields. Based on the fourth rearranged secret partition table, perform update operations in collaboration with other computing participants to update the secret partition of the arrangement number corresponding to the non-connected fields in the second replicated data partition table. in, The update operation includes: counting the number of times each tuple in the fourth rearranged secret partition table is copied in the second replicated secret partition table, with the number of copies of tuples not involved in the join being zero; calculating the initial sort number of each tuple with a non-zero copy number based on the copy number of each tuple in the fourth rearranged secret partition table, with the first tuple with a non-zero copy number having an initial sort number of one as the secret partition, and the initial sort numbers of other tuples being obtained by prefix summation of the copy number followed by one; copying each tuple based on the copy number of each tuple in the fourth rearranged secret partition table to form the fourth replicated secret partition table; traversing each tuple sequentially in the fourth replicated secret partition table, and comparing the non-join field value of the current tuple with the non-join field value of the previous tuple; if the non-join field values ​​of the two tuples are the same, setting the sort number of the current tuple to the sort number of the previous tuple plus one; if they are different, keeping the sort number of the current tuple unchanged.

15. A method for secure multi-party computation, applied to computational participants in a secure multi-party computation system as described in any one of claims 1 to 14, the method comprising: Receive and store secret tables sent by any data holder; Before executing the first query against the secret partition table, extract the secret shared column of the target field to be sorted from the secret partition table; Based on the secret shared column of the target field, a preset secure sorting algorithm is executed in collaboration with other computing participants to obtain the sorted secret shared column; Based on the sorted secret shared column, the secret fragments are determined in collaboration with other computing participants, and the sequence numbers of the arrangement numbers corresponding to each secret shared value in the sorted secret shared column are stored. Receive a query statement sent by any data querying party. If the query statement indicates a query for the data table corresponding to the secret partition table, rearrange the secret partition table in collaboration with other computing participants according to the secret partition of the sorting number corresponding to the target field in the data table, and obtain the rearranged secret partition table. Based on the rearranged secret partition table, the query operation indicated by the query statement is executed in collaboration with other computing participants.

16. An electronic device comprising: processor; A memory for storing processor-executable instructions; wherein the processor implements the steps of the method as claimed in claim 15 by executing the executable instructions.

17. A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, implement the steps of the method of claim 15.

18. A computer program product comprising a computer program / instructions that, when executed by a processor, implement the steps of the method as claimed in claim 15.

Images