A hierarchical dynamic hashing encrypted bucket batch positioning method and device

Abstract

This application provides a method and apparatus for batch locating encrypted buckets using hierarchical dynamic hashing. The method includes the following steps: obtaining a basic dataset for encrypted bucket location; performing hierarchical hash mapping calculation on the basic dataset to generate a set of candidate bucket row keys; performing batch reading and tag matching verification based on the candidate bucket row key set to generate candidate encrypted bucket matching results; and determining the location of the target encrypted bucket based on the candidate encrypted bucket matching results. Through the collaborative design of hierarchical progressive hash mapping, dynamic hash branching with progressively increasing bucket size, and a candidate bucket batch reading and tag matching verification mechanism, the efficiency and dynamic expansion capability of bucket location for encrypted data are significantly improved, achieving low-overhead batch bucket location while ensuring cryptographic security strength.

Description

Technical Field

[0001] This invention relates to the field of information security technology, specifically to a method and apparatus for batch locating encrypted buckets using hierarchical dynamic hashing. Background Technology

[0002] In the field of encrypted data storage and privacy computing, encrypted hash buckets are the core data structure for achieving anonymous data storage and encrypted retrieval. Through hash mapping, various access objects are mapped to corresponding encrypted buckets for storage. Combined with tag verification mechanisms, this enables precise data location and retrieval, and is widely used in zero-knowledge proof systems, encrypted databases, and privacy data retrieval scenarios. With the continuous growth of stored data volume and the increasing demand for concurrent access, the location efficiency and security of encrypted buckets directly determine the read / write performance and data protection capabilities of the entire encrypted storage system. The industry's requirements for the query efficiency, dynamic scalability, and batch processing capabilities of bucket location solutions are constantly increasing.

[0003] Currently, most mainstream encrypted bucket location schemes employ a single-layer fixed hash mapping mechanism, using a single hash function to map data objects to a fixed number of encrypted buckets. This approach has significant limitations in practical applications: reducing hash collision rates requires setting up a larger number of encrypted buckets, which significantly increases the number of IO interactions and storage management overhead during the query process; conversely, reducing the number of buckets to lower query overhead increases the data volume per bucket, leading to a significant increase in the computational cost of tag matching and decryption verification within the bucket. It remains difficult to achieve a balance between storage overhead, query efficiency, and collision control. Furthermore, the fixed bucket size of a single-layer hash mechanism necessitates full data rehashing and bucket migration when the total data volume dynamically increases, resulting in high expansion costs and long business interruptions, making it unsuitable for storage scenarios with dynamically changing data volumes.

[0004] Traditional scalable hashes typically rely on persistent directory entries, hierarchical pointer entries, or split pointers to maintain the expansion and mapping relationships between buckets. For cryptographically supported tables, additional directory or pointer structures not only significantly increase the storage volume of persistent metadata and the cost of maintaining transaction consistency, but the distribution characteristics of pointers and directories also expose hash expansion paths and data distribution patterns, introducing additional observable access paths and security attack surfaces. On the other hand, if each query probes buckets hierarchically and jumps through pointers level by level, multiple serial database round trips will occur in the SQL backend. The IO overhead of multi-level probing increases linearly with hash depth, significantly reducing retrieval efficiency. At the same time, the expansion operation of the pointer-based architecture requires synchronous updates to directory and pointer data, which can easily lead to transaction conflicts and business interruptions.

[0005] Furthermore, existing encrypted bucket location schemes mostly employ a single-bucket successive query approach, where a single calculation can only obtain the location of a single candidate bucket. This approach cannot acquire multi-level candidate bucket sets in batches, requiring multiple database interactions to complete the location and verification of the target bucket. This results in high read / write latency, making it difficult to support high-concurrency batch access scenarios. Simultaneously, the location process lacks layered security protection mechanisms. Some schemes simplify the tag verification process to improve efficiency, but this poses security risks such as leakage of mapping relationships and data enumeration. Other schemes use full-bucket decryption verification to ensure security, which incurs significant computational overhead. These approaches fail to achieve efficient batch bucket location while ensuring cryptographic security, making it difficult to meet the high-performance application requirements of large-scale encrypted storage systems. Summary of the Invention

[0006] In view of the aforementioned problems, this application is proposed to provide a hierarchical dynamic hashing encrypted bucket batch location method and apparatus to overcome or at least partially solve the aforementioned problems, comprising: A method for batch locating encrypted buckets using hierarchical dynamic hashing, wherein the method derives the positions of all candidate buckets on the same hash branch through a pointer-free deterministic hierarchical hash mapping, and completes the location verification by acquiring all candidate bucket data at once through a batch prefetching mechanism, including the following steps: Obtain the basic dataset for locating encrypted buckets; Perform hierarchical hash mapping calculations on the basic dataset for locating the encrypted buckets to generate a set of candidate bucket row keys; Based on the candidate bucket row key set, perform batch reading and tag matching verification to generate candidate encrypted bucket matching results; The location of the target encrypted bucket is determined based on the candidate encrypted bucket matching results.

[0007] Furthermore, the step of obtaining the basic dataset for locating the encrypted bucket includes: Obtain the target access object to be located and its corresponding search key; Retrieve the preset hierarchical hash bucket size configuration parameters; The encrypted bucket location base dataset is generated using the target access object, the search key, and the hierarchical hash bucket size configuration parameters.

[0008] Further, the step of performing hierarchical hash mapping calculations based on the encrypted bucket location base dataset to generate a candidate bucket row key set includes: Based on the target access object and the search key, a cryptographic derivation is performed to obtain the complete internal tag; Based on the hierarchical hash bucket size configuration parameters and the complete internal label, a deterministic mapping calculation is performed to obtain the candidate bucket row keys corresponding to each level under the same hash branch; Summarize the candidate bucket row keys from all levels to generate a candidate bucket row key set.

[0009] Furthermore, the step of performing hierarchical hash mapping calculations on the underlying dataset located by the encrypted bucket further includes: Based on preset incremental rules, set the bucket size values ​​corresponding to each level to generate a hierarchical bucket size sequence; By using the hierarchical bucket size sequence and complete internal labels, the candidate bucket row keys of each level on the same dynamic hash branch are derived sequentially.

[0010] Further, the step of performing batch reading and tag matching verification based on the candidate bucket row key set to generate candidate encrypted bucket matching results includes: Perform a batch prefetch database read on the candidate bucket row key set to obtain the candidate encrypted bucket data for all levels in one database interaction; The candidate encrypted bucket data is authenticated and decrypted. The identification information corresponding to the complete internal tag is matched in the decrypted bucket records to obtain the matching status of the candidate encrypted bucket. Based on the matching status, candidate encrypted bucket matching results are generated.

[0011] Further, the step of determining the location of the target encryption bucket based on the candidate encryption bucket matching results includes: The target access bucket is determined based on the candidate encrypted bucket matching results; The writable bucket is determined by the remaining storage space of the candidate encrypted packets; Based on the location information of the target access bucket and the writable bucket and the corresponding operation type, a target encrypted bucket location and operation decision result is generated.

[0012] Furthermore, it also includes: In the data writing scenario, based on the target encrypted bucket location and operation decision results, a data update operation is performed on the target access bucket, a new data writing operation is performed on the writable bucket, or a new encrypted bucket of the corresponding level is created.

[0013] A hierarchical dynamic hashing encrypted bucket batch location device, the device implementing the steps of the hierarchical dynamic hashing encrypted bucket batch location method described above: include: The acquisition module is used to acquire the basic dataset for locating encrypted buckets. The candidate bucket row key set module is used to perform hierarchical hash mapping calculations based on the encrypted bucket location base dataset to generate a candidate bucket row key set. The matching result module is used to perform batch reading and tag matching verification based on the candidate bucket row key set, and generate candidate encrypted bucket matching results; The target encryption bucket location module is used to determine the location of the target encryption bucket based on the candidate encryption bucket matching results.

[0014] A computer electronic device includes a processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein the computer program, when executed by the processor, implements the method described in any of the preceding descriptions.

[0015] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in any of the preceding claims.

[0016] This application has the following advantages: In the embodiments of this application, compared with the existing technology where single-layer fixed hash mapping is difficult to balance storage overhead, query efficiency and hash collision control, the cost of full rehashing expansion is high and the business interruption is long when the data scale grows dynamically, the database interaction is frequent and the batch positioning efficiency is low in the single-bucket successive query mode, and it is difficult to balance security verification and positioning performance, this application provides a layered dynamic hashing encrypted bucket batch positioning method. The method derives the position of all-level candidate buckets on the same hash branch through pointerless deterministic layered hash mapping, and completes the positioning verification by acquiring all candidate bucket data at once through a batch prefetching mechanism. The method is used to achieve high-security, high-throughput encrypted bucket batch positioning and read-write adaptation in encrypted storage scenarios, including the following steps: obtaining the encrypted bucket positioning basic dataset; performing layered hash mapping calculation on the encrypted bucket positioning basic dataset to generate a candidate bucket row key set; performing batch reading and tag matching verification based on the candidate bucket row key set to generate candidate encrypted bucket matching results; and determining the target encrypted bucket positioning based on the candidate encrypted bucket matching results. By employing a layered progressive hash mapping, a dynamic hash branch design with progressively increasing bucket size, and a collaborative design of candidate bucket batch reading and tag matching verification mechanisms, this approach resolves the core contradictions in traditional encrypted bucket location schemes, such as the imbalance between security strength and query efficiency, high dynamic expansion costs, and insufficient batch processing capabilities. It significantly improves the efficiency of bucket location and dynamic expansion capabilities for encrypted data, achieving low-overhead batch bucket location while ensuring cryptographic security. It eliminates the need to reduce verification levels for query speed or rely on large bucket sizes to mitigate collision risks. It is fully compatible with mainstream encrypted storage architectures and database access protocols, requires no additional dedicated storage components, and does not increase engineering implementation or security verification costs. It ensures the security protection capabilities of encrypted data against enumeration and collision, while also meeting the smooth expansion needs under the dynamic growth of large-scale data. It supports unified bucket positioning logic for various business scenarios such as querying, writing, and expansion. It can be adapted to various deployment environments such as general servers, distributed storage clusters, and privacy computing nodes. It can be directly integrated into existing encrypted databases and privacy storage systems with low transformation and adaptation costs and high read and write execution efficiency. It balances the high security, high throughput efficiency, dynamic expansion capabilities, and practicality of encrypted bucket positioning in engineering implementation. Attached Figure Description

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

[0018] Figure 1 This is a flowchart illustrating the steps of a hierarchical dynamic hashing encrypted bucket batch location method provided in an embodiment of this application; Figure 2 This is a structural block diagram of a hierarchical dynamic hash encrypted bucket batch positioning device provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention; 1. Computer equipment; 2. External devices; 3. Processing unit; 4. Bus; 5. Network adapter; 6. I / O interface; 7. Display; 8. Memory; 9. Random access memory; 10. Cache memory; 11. Storage system; 12. Program / utility; 13. Program module. Detailed Implementation

[0019] To make the objectives, features, and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0020] The inventors, through analysis of existing technologies, discovered that most mainstream encrypted bucket location schemes currently employ a single-layer fixed hash mapping mechanism, using a single hash function to map data objects to a fixed number of encrypted buckets. This type of scheme has significant limitations in practical applications: to reduce hash collision rates, a larger number of encrypted buckets is required, which significantly increases the number of IO interactions and storage management overhead during the query process; if the number of buckets is reduced to lower query overhead, the data volume per bucket increases, leading to a significant increase in the computational cost of tag matching and decryption verification within the bucket, making it difficult to achieve a balance between storage overhead, query efficiency, and collision control. Furthermore, the fixed bucket size of a single-layer hash mechanism necessitates full data rehashing and bucket migration when the total data volume dynamically increases, resulting in high expansion costs and long business interruption times, making it unsuitable for storage scenarios with dynamically changing data volumes.

[0021] Reference Figure 1 This application illustrates a method for batch locating encrypted buckets using hierarchical dynamic hashing, according to an embodiment of the present application. The method derives the positions of all candidate buckets on the same hash branch through a pointer-free deterministic hierarchical hash mapping, and completes the location verification by acquiring all candidate bucket data at once through a batch prefetching mechanism. The method includes the following steps: S110. Obtain the basic dataset for encrypted bucket location; S120. Perform hierarchical hash mapping calculation on the encrypted bucket location basic dataset to generate a candidate bucket row key set; S130. Perform batch reading and tag matching verification based on the candidate bucket row key set to generate candidate encrypted bucket matching results; S140. Determine the location of the target encryption bucket based on the candidate encryption bucket matching results.

[0022] In the embodiments of this application, compared with the existing technology where single-layer fixed hash mapping is difficult to balance storage overhead, query efficiency and hash collision control, the cost of full rehashing expansion is high and the business interruption is long when the data scale grows dynamically, the database interaction is frequent and the batch positioning efficiency is low in the single-bucket successive query mode, and it is difficult to balance security verification and positioning performance, this application provides a layered dynamic hashing encrypted bucket batch positioning method. The method derives the position of all-level candidate buckets on the same hash branch through pointerless deterministic layered hash mapping, and completes the positioning verification by acquiring all candidate bucket data at once through a batch prefetching mechanism. The method is used to achieve high-security, high-throughput encrypted bucket batch positioning and read-write adaptation in encrypted storage scenarios, including the following steps: obtaining the encrypted bucket positioning basic dataset; performing layered hash mapping calculation on the encrypted bucket positioning basic dataset to generate a candidate bucket row key set; performing batch reading and tag matching verification based on the candidate bucket row key set to generate candidate encrypted bucket matching results; and determining the target encrypted bucket positioning based on the candidate encrypted bucket matching results. By employing a layered progressive hash mapping, a dynamic hash branch design with progressively increasing bucket size, and a collaborative design of candidate bucket batch reading and tag matching verification mechanisms, this approach resolves the core contradictions in traditional encrypted bucket location schemes, such as the imbalance between security strength and query efficiency, high dynamic expansion costs, and insufficient batch processing capabilities. It significantly improves the efficiency of bucket location and dynamic expansion capabilities for encrypted data, achieving low-overhead batch bucket location while ensuring cryptographic security. It eliminates the need to reduce verification levels for query speed or rely on large bucket sizes to mitigate collision risks. It is fully compatible with mainstream encrypted storage architectures and database access protocols, requires no additional dedicated storage components, and does not increase engineering implementation or security verification costs. It ensures the security protection capabilities of encrypted data against enumeration and collision, while also meeting the smooth expansion needs under the dynamic growth of large-scale data. It supports unified bucket positioning logic for various business scenarios such as querying, writing, and expansion. It can be adapted to various deployment environments such as general servers, distributed storage clusters, and privacy computing nodes. It can be directly integrated into existing encrypted databases and privacy storage systems with low transformation and adaptation costs and high read and write execution efficiency. It balances the high security, high throughput efficiency, dynamic expansion capabilities, and practicality of encrypted bucket positioning in engineering implementation.

[0023] It should be noted that this method can be widely applied to various secure storage scenarios that require concealing the true storage location of data, such as encrypted key-value storage, encrypted database indexing, privacy computing data addressing, and zero-knowledge proof data buckets. The total number of hierarchical hash levels and the size of each bucket level can be flexibly configured according to the business data volume, security level requirements, and read / write performance goals. It can be adapted to general large-scale storage scenarios using a standard three-layer hierarchical architecture, or reduced to a two-layer lightweight architecture to adapt to resource-constrained scenarios such as embedded and edge devices. Parameter adjustments do not require modification of the core mapping algorithm, demonstrating strong business adaptability.

[0024] This method can output the row keys of all candidate buckets through a single hierarchical hash calculation. The corresponding storage access only needs to perform a batch read operation to obtain all candidate bucket data. Compared with the traditional single-bucket serial query mode, it can significantly reduce the number of storage IO interactions and effectively reduce system latency and storage node pressure under high concurrency access.

[0025] Meanwhile, the dynamic expansion of this solution does not require rehashing and bucket migration of the entire data. Capacity expansion is achieved simply by adding a new encrypted bucket at the end of the hash branch. The expansion process does not interrupt read / write services for existing data, enabling smooth and seamless elastic scaling of storage capacity. Furthermore, the label matching verification of this method is based on cryptographically secure internal labels. The matching process does not require decrypting the complete business data within the bucket; accurate matching can be achieved solely through the bucket head identifier information. While ensuring that data mapping relationships are not enumerable and original data is not leaked, the computational overhead of decryption verification is effectively controlled, achieving a balance between security strength and access performance.

[0026] A purely deterministic mapping approach replaces the traditional pointer-based routing architecture. The database storage only retains a binary storage structure of bucket row keys and corresponding encrypted bucket values, without storing any hierarchical directory entries, inter-bucket pointer entries, split forwarding tables, or expansion routing metadata. The row key positions of all candidate buckets are derived layer by layer by the trusted execution end using a deterministic hash function based on complete internal tags and a preset increasing bucket size sequence. The entire derivation process does not require any pointer queries or directory read requests to the database. The same complete internal tag always corresponds to a unique hash branch path and candidate bucket row key under the same bucket size configuration, ensuring complete reproducibility and consistency. Dynamic expansion of hash branches only requires updating the bucket size sequence configuration parameters on the trusted execution end, without requiring any metadata modification or pointer redirection of the database inventory data, completely eliminating the transaction consistency maintenance overhead caused by pointer-based metadata.

[0027] Compared to traditional pointer-dependent scalable hashing schemes, pointer-free technology simultaneously achieves triple benefits: reduced storage overhead, enhanced security protection, and improved engineering adaptability. At the storage level, it eliminates the need for persistent storage of full pointers and directory metadata; the larger the data volume, the more significant the storage space savings, while avoiding transaction conflicts and lock overhead caused by pointer updates. At the security level, it eliminates the risk of observable features such as pointer distribution and directory structure exposing data distribution patterns and hash expansion paths, significantly reducing the side-channel attack surface and matching the encrypted storage security requirements of encrypted buckets. At the engineering implementation level, the purely computation-driven location logic does not require modification of the underlying database table structure and can be directly implemented based on the key-value tables of standard relational databases, compatible with the native capabilities of existing databases such as batch queries and transaction control, resulting in extremely low deployment and adaptation costs.

[0028] As described in step S110, obtain the basic dataset for locating the encrypted bucket.

[0029] It should be noted that the encrypted bucket location dataset provides a complete input basis for subsequent hierarchical hash mapping and bucket verification. Its generation process is carried out in a controlled and secure environment. The original sensitive information will not be exposed in plaintext on the storage access link, ensuring access privacy and data security during the location process.

[0030] In one embodiment of the present invention, the specific process of "obtaining the basic dataset for locating the encrypted bucket" in step S110 can be further described in conjunction with the following description.

[0031] As described in the following steps, obtain the target access object to be located and the corresponding search key; It should be noted that the target access object is a cryptographic data identifier, index key value, or privacy data entry to be addressed, written, or verified, which can correspond to a single data record, data set, or data fragment; the search key is a secret derived credential held by the accessing party, used for the cryptographic generation of subsequent internal tags. The server can only complete the mapping calculation based on the search key and cannot deduce the original plaintext meaning of the target access object, thereby ensuring the privacy of the access behavior and preventing the leakage of access patterns.

[0032] Obtain the preset hierarchical hash bucket size configuration parameters as described in the following steps; It should be noted that the configuration parameters for the hierarchical hash bucket size include at least the total number of hash layers, the number of buckets at each layer, the bucket size increment coefficient, and the hash mapping algorithm identifier. These parameters can be pre-configured according to the overall data scale of the system, the security protection level, and the read / write performance goals, or they can be dynamically adjusted according to the data growth. Typically, the bucket size increases by a preset ratio as the hierarchy deepens, forming a tree-shaped hash branch structure that is narrow at the top and wide at the bottom, which controls the probability of collisions while avoiding excessive expansion of the number of buckets at the bottom layer.

[0033] As described in the following steps, a basic dataset for locating encrypted buckets is generated using the target access object, the search key, and the hierarchical hash bucket size configuration parameters; It should be noted that the generated encrypted bucket location base dataset is standardized structured input data, which unifies the input format of subsequent hierarchical hash calculations, ensuring that the same target access object always outputs consistent mapping results under the same configuration parameters, thus guaranteeing the determinism and reproducibility of the location process; this dataset only contains the necessary parameters required for derivation operations and does not carry any additional business-sensitive information, and can be securely transmitted to subsequent hash calculation and storage access stages.

[0034] As described in step S120, a hierarchical hash mapping calculation is performed on the basic dataset for locating the encrypted bucket to generate a set of candidate bucket row keys.

[0035] It should be noted that this step derives the candidate bucket positions at each level layer by layer along a single hash branch based on the same internal label. The entire process can output the candidate bucket identifiers at all levels at once without any additional storage interaction. Compared with the single-level hash scheme, the hierarchical tree structure can significantly reduce the total bucket size under the same collision probability, while realizing the batch generation of multiple candidate buckets, laying the foundation for subsequent batch reading and verification, and effectively balancing mapping security and addressing execution efficiency.

[0036] In one embodiment of the present invention, the specific process of "performing hierarchical hash mapping calculation on the basic dataset for locating the encrypted bucket and generating a set of candidate bucket row keys" in step S120 can be further described in conjunction with the following description.

[0037] As described in the following steps, a cryptographic derivation is performed based on the target access object and the search key to obtain the complete internal tag; It should be noted that the complete internal label is generated by a cryptographic hash function or key derivation function with a key, using the search key as the derived key and the target access object as the input factor, and a fixed-length label value is obtained through a one-way irreversible transformation. This label possesses cryptographic uniqueness and unforgeability. Only the accessee holding the corresponding search key can generate a consistent internal label. The server cannot infer the original information of the target access object from the label, which ensures the determinism of subsequent mapping calculations and avoids the leakage of data identification and access patterns, providing a secure comparison benchmark for subsequent bucket matching verification.

[0038] As described in the following steps, a deterministic mapping calculation is performed based on the hierarchical hash bucket size configuration parameters and the complete internal label to obtain the candidate bucket row keys corresponding to each level under the same hash branch; It should be noted that the hierarchical mapping is performed layer by layer from top to bottom along the same hash branch. Each level extracts different bit segments of the complete internal label and performs deterministic modulo operation based on the bucket size value of the current level to obtain the unique candidate bucket row key for that level. The bucket size of each level increases with depth, and a single bucket in the upper level corresponds to multiple sub-buckets in the lower level. All candidate buckets belong to the same hash branch path, and there are no redundant candidate buckets across branches. This ensures a low collision probability and keeps the number of candidate buckets within the range of the number of levels, avoiding invalid read overhead. The entire mapping process is a deterministic computation, and the same input always yields a consistent bucket row key result, which is suitable for the multi-node consistent addressing requirements of distributed storage clusters.

[0039] As described in the following steps, the candidate bucket row keys of all levels are aggregated to generate a candidate bucket row key set.

[0040] It should be noted that the generated candidate bucket row key set contains unique identifiers for candidate buckets at all levels of the hash branch. Each bucket row key adopts a unified encoding format, which can be directly adapted to the batch read interfaces of key-value databases and distributed storage systems. Only one storage IO interaction is needed to retrieve all candidate bucket data, replacing the traditional single-bucket serial multiple query mode, which significantly reduces the network latency and scheduling overhead of storage access. The bucket row keys in the set are arranged in hierarchical order, which facilitates the comparison according to hierarchical priority during subsequent matching and verification, thereby improving the location and convergence speed.

[0041] In one embodiment of the present invention, the step "perform hierarchical hash mapping calculation on the basic dataset for locating the encrypted bucket" further includes: As described in the following steps, set the bucket size value corresponding to each level according to the preset incremental rule to generate a hierarchical bucket size sequence; It should be noted that the preset increment rule can adopt various methods such as proportional increment, fixed step increment, or custom increment. The bucket size increases with the depth of the hierarchy, forming a tree-shaped bucket structure with upper-level convergence and lower-level expansion. Using a smaller bucket size in the upper layer can quickly reduce the addressing range and reduce the top-level storage management overhead, while using a larger bucket size in the lower layer can effectively distribute data storage density and control the probability of hash collisions. In this way, under the premise of controllable total number of buckets, it can achieve collision resistance performance far superior to single-level hashing.

[0042] The hierarchical bucket size sequence provides a unified modular benchmark for the entire process of mapping calculation. The sequence parameters can be flexibly revised according to the growth of the total system data, the adjustment of security level, or the optimization of performance indicators. The revision process does not require changes to the core mapping algorithm logic; only the configuration parameters need to be updated to take effect, which has extremely strong configuration flexibility and business adaptability.

[0043] As described in the following steps, the candidate bucket row keys of each level on the same dynamic hash branch are derived sequentially using the hierarchical bucket size sequence and the complete internal label; It should be noted that the derivation process is executed layer by layer from top to bottom along the hash branch. Based on the same complete internal label, the effective bit segments of the corresponding level are extracted respectively. Deterministic modulo operation is performed in combination with the bucket size value of the current level to obtain the unique candidate bucket row key of each level. All candidate buckets belong to the same continuous hash storage branch, and the upper-level bucket is the parent node of the lower-level bucket. There are no redundant candidate buckets across branches. The number of candidate buckets located in a single time can be strictly controlled within the total number of layers, avoiding the additional read overhead caused by invalid candidate buckets.

[0044] The derivation process involves only lightweight calculations such as bitwise operations and modular operations, with low computational complexity and short execution latency, which can support massive addressing requests in high-concurrency scenarios. At the same time, the hash branch supports dynamic downward expansion. When expanding the data, it is only necessary to add a new level at the end and set the corresponding bucket size. There is no need to perform full rehashing and bucket migration on the existing data, so as to achieve smooth dynamic expansion of storage capacity.

[0045] As described in step S130, perform batch reading and tag matching verification based on the candidate bucket row key set to generate candidate encrypted bucket matching results.

[0046] It should be noted that by pulling all candidate bucket data through a single batch storage interaction, and then performing precise matching verification based on cryptographic internal tags, multiple serial I / O operations are compressed into a single batch operation, significantly reducing network latency and scheduling overhead for storage access. The matching verification process is only performed on the identification information within the bucket, without needing to decrypt the complete business data. Under the premise of ensuring data storage security and access privacy, the resource overhead of decryption computation is effectively controlled, achieving a balance between high security and high performance.

[0047] In one embodiment of the present invention, the specific process of step S130, "performing batch reading and tag matching verification based on the candidate bucket row key set to generate candidate encrypted bucket matching results," can be further explained in conjunction with the following description.

[0048] As described in the following steps, a batch prefetch database read is performed on the candidate bucket row key set to obtain candidate encrypted bucket data for all levels in one database interaction. It should be noted that batch read directly calls the batch query interface of the underlying storage, and pulls all encrypted bucket data corresponding to the candidate bucket row key set at once. This replaces the serial mode of querying a single bucket one by one in the traditional solution, compressing the number of storage interactions from being positively correlated with the number of levels to a fixed 1 time, which greatly reduces the database connection overhead and network round-trip latency in high-concurrency scenarios.

[0049] During the reading process, all candidate bucket data is transmitted in encrypted form. The storage node can only be aware of the batch read operation and cannot distinguish which candidate bucket is the target access bucket. This can effectively resist access pattern analysis attacks and protect the privacy of data addressing behavior.

[0050] Batch prefetching database reads are based on the one-time derivation of candidate bucket row keys at all levels under a pointerless architecture. They can directly package candidate bucket row keys at all levels on the same hash branch into a single batch query request, and call the native multi-row read and batch key-value query capabilities of relational databases to perform data retrieval.

[0051] Compared to the traditional hierarchical hashing approach of probing layer by layer and jumping to the next layer only after a miss, this mechanism compresses the number of database interactions from multiple serial I / Os that are positively correlated with the number of hash levels to a fixed single batch I / O. This significantly reduces network round-trip latency and database connection scheduling overhead, with performance improvements becoming more pronounced the deeper the hash layer. Simultaneously, the storage end can only perceive one batch read operation and cannot distinguish the hierarchical priority and target affiliation of each candidate bucket from the access behavior, thus avoiding the leakage of access path characteristics and matching the access privacy requirements of encrypted storage.

[0052] In one embodiment of the present invention, step S130, "performing a batch prefetch database read on the candidate bucket row key set", further includes a batch prefetch process in the scenario of searching consecutive second-level identifier set blocks: It should be noted that when traversing consecutive sets of secondary identifiers (such as sequentially scanning multiple data fragments or contiguous storage blocks), the block numbers of multiple consecutive sets of secondary identifiers are obtained and used as multiple secondary block numbers. Multiple complete internal tags are derived from the multiple secondary block numbers respectively; then, according to the preset batch size, the candidate bucket row keys obtained by mapping the multiple complete internal tags are merged to construct multiple candidate bucket row key sets.

[0053] Perform batch prefetch database reads on the multiple candidate bucket row key sets, and cache the read candidate encrypted bucket data to the trusted execution end.

[0054] This process enables "batch within batch" prefetching: not only are single objects read in batches across levels, but the full-level row keys of multiple consecutive objects are merged into a larger batch query request, allowing all candidate bucket data corresponding to multiple secondary identifier sets to be retrieved in a single database interaction.

[0055] By compressing the multiple serial queries required for continuous traversal into a single merged batch read, the number of database round trips and network overhead in sequential scanning scenarios is significantly reduced; the cached data is used for subsequent tag matching verification in each secondary block without repeated database access, which greatly improves the traversal and retrieval efficiency of continuous storage areas.

[0056] As described in the following steps, the candidate encrypted bucket data is authenticated and decrypted, and the identification information corresponding to the complete internal tag is matched in the decrypted bucket records to obtain the matching status of the candidate encrypted bucket; It should be noted that the authentication and decryption process prioritizes verifying the message authentication code of the encrypted bucket. After confirming that the bucket data has not been tampered with and that the source is legitimate, only the tag identification field within the bucket is decrypted. There is no need to perform decryption operations on all business data within the bucket, which significantly reduces the amount of decryption computation and lowers computing power consumption.

[0057] The matching process uses the pre-generated complete internal label as the sole comparison benchmark and adopts constant time comparison logic with a fixed duration to avoid time-series side-channel attacks. The candidate bucket is determined to be a successful match only when the identification information recorded in the bucket is completely consistent with the complete internal label; otherwise, it is determined to be a non-match, ensuring the accuracy and security of the positioning results.

[0058] As described in the following steps, candidate encryption bucket matching results are generated based on the matching status; It should be noted that the generated candidate cryptographic bucket matching results include structured information such as the hierarchical sequence number, bucket row key, matching status, and bucket capacity metadata of each candidate bucket. The matching status is divided into three categories: successful match, no match, and bucket does not exist, which can clearly reflect the hit status of each level of bucket on the hash branch.

[0059] The matching results are sorted in hierarchical order, which can directly provide a complete input basis for subsequent target bucket location, write location determination, and dynamic expansion decision-making; the standardized result format can be directly adapted to various business scenarios such as read, write, delete, and expansion without additional data format conversion, thus improving the efficiency of the entire chain processing.

[0060] As described in step S140, the location of the target encryption bucket is determined based on the candidate encryption bucket matching results.

[0061] It should be noted that the system not only outputs the bucket storage location corresponding to the target data, but also generates corresponding operation decisions by combining the bucket capacity status and business operation type. This uniformly covers multiple business scenarios such as data query, data writing, and dynamic expansion, avoiding repeated execution of the location process under different operation scenarios. It achieves one-time location and reuse in multiple scenarios, effectively improving the overall efficiency of end-to-end addressing and business execution. The location result also carries metadata such as hierarchical attributes and storage status, which can provide decision-making basis for capacity scheduling and load balancing of the upper-layer storage system.

[0062] In one embodiment of the present invention, the specific process of "determining the location of the target encryption bucket based on the candidate encryption bucket matching result" in step S140 can be further explained in conjunction with the following description.

[0063] The target access bucket is determined based on the candidate encrypted bucket matching results as described in the following steps; It should be noted that the target access bucket corresponds to a successfully matched candidate encrypted bucket, i.e., the encrypted bucket storing the data corresponding to the target access object. During the determination, the matching results are checked sequentially from deepest to shallowest priority, and the deepest successfully matched bucket is returned first to ensure that the location is located at the lowest level of the actual data storage node, ensuring the accuracy of subsequent read operations. If none of the candidate buckets at all levels match successfully, it is determined that the target data does not exist, and the corresponding miss status is returned. The entire determination process is executed based on the completed batch matching results, without the need to initiate additional storage access, and can quickly output the location conclusion of query-type operations.

[0064] As described in the following steps, the writable bucket is determined by the remaining storage space of the candidate encrypted token; It should be noted that writable buckets are used to determine the write location in data writing scenarios. The remaining storage space is checked starting from the candidate bucket at the bottom of the hash branch. If the remaining capacity of the bottom bucket meets the current write requirements, it is directly determined to be a writable bucket. If the bottom bucket has reached its capacity limit, it backtracks to the upper-level candidate bucket to continue the check. If none of the layered candidate buckets meet the write conditions, it is determined that a new layer of encrypted bucket needs to be added at the end of the branch.

[0065] The remaining storage space verification is performed based on the bucket metadata obtained synchronously during batch reading. There is no need to initiate a separate capacity query request. The write position can be pre-determined during the positioning stage, which effectively reduces additional storage interaction overhead.

[0066] As described in the following steps, based on the location information of the target access bucket and the writable bucket and the corresponding operation type, a target encrypted bucket location and operation decision result is generated; It should be noted that the operation decision results are generated differently based on the type of business operation: query operations output the location information of the target access bucket and read operation instructions; write operations output the location information of the writable bucket and write and update operation instructions; when capacity is insufficient, a new bucket creation decision and corresponding level configuration are output simultaneously. All decisions are generated based on the matching results of the same location, ensuring that the addressing benchmark for read and write operations is consistent and avoiding data consistency deviations caused by multiple locations; the standardized location and decision results can be directly connected to the upper-layer storage execution engine without additional format parsing and conversion, supporting fast read and write scheduling in high-concurrency scenarios.

[0067] In one embodiment of the present invention, it further includes: In the data writing scenario, based on the target encrypted bucket location and operation decision results, a data update operation is performed on the target access bucket, a new data writing operation is performed on the writable bucket, or a new encrypted bucket of the corresponding level is created. It should be noted that all operations in this step are performed based on the decision results output by the preceding positioning process, without the need to repeatedly execute hash mapping and bucket addressing, ensuring the consistency between the write operation and the positioning benchmark, and effectively reducing the computation and IO overhead of the entire write chain.

[0068] For existing target access objects, in-situ data updates are performed directly on the matched target access bucket, keeping the data storage location unchanged and eliminating the need for cross-bucket migration. This ensures the stability of the data mapping relationship and avoids the chain reaction of expansion caused by update operations. For new data writing scenarios, data is prioritized to be written to the writable bucket at the lowest level of the hash branch, ensuring that the data is always stored at the deepest level of the mapping path. This maintains the collision resistance of the hierarchical hash structure. During the writing process, the tag index and capacity metadata within the bucket are updated simultaneously, ensuring that subsequent location queries can accurately hit the target. When all candidate buckets at all levels of the current hash branch have reached their capacity limits, a new encrypted bucket at the corresponding level is automatically created at the end of the branch. The expansion process only involves the initialization of the new bucket and metadata registration, without the need to perform rehashing and data migration on existing encrypted buckets. This does not interrupt the read and write services of existing data, enabling smooth and seamless expansion of storage capacity and completely solving the expansion pain point of full rehashing in single-level hash schemes.

[0069] All write operations are completed using an authentication and encryption mechanism. The written data is stored and transmitted in encrypted form throughout the entire process. The tags in the bucket and the business data are written synchronously with encryption, without leaking any plaintext information, thus ensuring data security and access privacy during the write process. This write execution logic can seamlessly connect to various underlying storage media such as key-value databases and distributed object storage. It can adapt to the encrypted storage business needs of different scales and security levels without modifying the core hierarchical hash rules.

[0070] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0071] Reference Figure 2 This illustration shows a hierarchical dynamic hash encrypted bucket batch location device according to an embodiment of this application, the device implementing the steps of hierarchical dynamic hash encrypted bucket batch location as described in any of the above claims: include: Module 210 is used to acquire the basic dataset for locating encrypted buckets; The candidate bucket row key set module 220 is used to perform hierarchical hash mapping calculation based on the encrypted bucket location basic dataset to generate a candidate bucket row key set; The matching result module 230 is used to perform batch reading and tag matching verification based on the candidate bucket row key set to generate candidate encrypted bucket matching results; The target encryption bucket positioning module 240 is used to determine the target encryption bucket positioning based on the candidate encryption bucket matching results.

[0072] In one embodiment of the present invention, the acquisition module 210 includes: The target access object submodule is used to obtain the target access object to be located and the corresponding search key; The configuration parameters submodule is used to obtain the preset hierarchical hash bucket size configuration parameters; The basic dataset submodule is used to generate a cryptographic bucket location basic dataset using the target access object, the search key, and the hierarchical hash bucket size configuration parameters.

[0073] In one embodiment of the present invention, the candidate bucket row key set module 220 includes: A complete internal tag derivation submodule is used to perform cryptographic derivation based on the target access object and the search key to obtain the complete internal tag; The layered bucket size sequence submodule is used to set the bucket size value corresponding to each level according to a preset incremental rule, and generate a layered bucket size sequence. The hierarchical row key mapping submodule is used to perform deterministic mapping calculations with the complete internal label based on the hierarchical hash bucket size configuration parameters to obtain the candidate bucket row keys corresponding to each level under the same hash branch; The candidate set aggregation submodule is used to aggregate the candidate bucket row keys of all levels and generate a candidate bucket row key set.

[0074] In one embodiment of the present invention, the candidate bucket row key set module 220 further includes: The layered bucket size sequence submodule is used to set the bucket size value corresponding to each level according to a preset incremental rule, and generate a layered bucket size sequence. The candidate bucket row key derivation submodule is used to derive the candidate bucket row keys of each level on the same dynamic hash branch sequentially using the hierarchical bucket size sequence and the complete internal label.

[0075] In one embodiment of the present invention, the matching result module 230 includes: The candidate bucket batch reading submodule is used to perform batch database reading on the candidate bucket row key set to obtain the corresponding candidate encrypted bucket data; The decryption tag matching submodule is used to authenticate and decrypt the candidate encrypted bucket data, and match the identification information corresponding to the complete internal tag in the decrypted bucket records to obtain the matching status of the candidate encrypted bucket. The matching result output submodule is used to generate candidate encrypted bucket matching results based on the matching status.

[0076] In one embodiment of the present invention, the target encryption bucket positioning module 240 includes: The target access bucket determination submodule is used to determine the target access bucket based on the candidate encrypted bucket matching results; The writable bucket determination submodule is used to determine the writable bucket based on the remaining storage space of the candidate encrypted buckets; The location decision generation submodule is used to generate the target encrypted bucket location and operation decision results based on the location information of the target access bucket and the writable bucket and the corresponding operation type.

[0077] In one embodiment of the present invention, the apparatus further includes a write execution module, used to perform corresponding bucket operations in a data write scenario, the write execution module comprising: The data update submodule is used to perform data update operations on the target access bucket based on the target encrypted bucket location and operation decision results; the data writing submodule is used to perform new data writing operations on the writable bucket. The new bucket creation submodule is used to create new encrypted buckets at the corresponding level.

[0078] Reference Figure 3 The diagram illustrates a computer device for implementing a hierarchical dynamic hashing method for batch locating encrypted buckets according to the present invention, which may specifically include the following: The aforementioned computer device 1 is in the form of a general-purpose computing device. The components of the computer device 1 may include, but are not limited to: one or more processors or processing units 3, memory 8, and a bus 4 connecting different system components (including memory 8 and processing unit 3).

[0079] Bus 4 represents one or more of several bus architectures, including memory buses or memory controllers, peripheral buses, graphics acceleration ports, processors, or local buses using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Audio / Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0080] Computer device 1 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by computer device 1, including volatile and non-volatile media, removable and non-removable media.

[0081] Memory 8 may include computer system readable media in the form of volatile memory, such as random access memory 9 and / or cache memory 10. Computer device 1 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 11 may be used to read and write non-removable, non-volatile magnetic media (commonly referred to as a "hard disk drive"). Although Figure 3 As not shown, a disk drive for reading and writing to a removable non-volatile disk (such as a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (such as a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 4 via one or more data media interfaces. The memory may include at least one program product having a set (e.g., at least one) of program modules 13 configured to perform the functions of the embodiments of this application.

[0082] A program / utility 12 having a set (at least one) of program modules 13 may be stored, for example, in memory. Such program modules 13 include—but are not limited to—an operating system, one or more application programs, other program modules 13, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 13 typically perform the functions and / or methods described in the embodiments of this application.

[0083] Computer device 1 can also communicate with one or more external devices 2 (e.g., keyboard, pointing device, monitor 7, camera, etc.), and with one or more devices that enable an operator to interact with computer device 1, and / or with any device that enables computer device 1 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed through I / O interface 6. Furthermore, computer device 1 can communicate with one or more networks (e.g., local area network (LAN)), wide area network (WAN), and / or public networks (e.g., the Internet) through network adapter 5, and can also exchange data via medical data network protocols such as ICD protocol, DICOM protocol, and HL7 protocol. Figure 3 As shown, network adapter 5 communicates with other modules of computer device 1 via bus 4. It should be understood that, although... Figure 3 Not shown, it can be combined with computer device 1 to use other hardware and / or software modules, including but not limited to: microcode, device drivers, redundant processing unit 3, external disk drive array, RAID system, tape drive and data backup storage system 11, etc.

[0084] The processing unit 3 executes various functional applications and data processing by running programs stored in memory 8, such as implementing a hierarchical dynamic hashing encrypted bucket batch location method provided in the embodiments of this application.

[0085] That is, when the above-mentioned processing unit 3 executes the above-mentioned program, it achieves the following: obtaining the basic dataset for locating the encrypted bucket; Perform hierarchical hash mapping calculations on the basic dataset for locating the encrypted buckets to generate a set of candidate bucket row keys; Based on the candidate bucket row key set, perform batch reading and tag matching verification to generate candidate encrypted bucket matching results; The location of the target encrypted bucket is determined based on the candidate encrypted bucket matching results.

[0086] In this application embodiment, this application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements a hierarchical dynamic hashing encrypted bucket batch location method as provided in all embodiments of this application.

[0087] That is, when the program is executed by the processor, it should implement: obtaining the basic dataset for locating the encrypted bucket; Perform hierarchical hash mapping calculations on the basic dataset for locating the encrypted buckets to generate a set of candidate bucket row keys; Based on the candidate bucket row key set, perform batch reading and tag matching verification to generate candidate encrypted bucket matching results; The location of the target encrypted bucket is determined based on the candidate encrypted bucket matching results.

[0088] Any combination of one or more computer-readable media may be used. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in connection with an instruction execution system, apparatus, or device.

[0089] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including—but not limited to—electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of transmitting, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0090] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof. These programming languages ​​include object-oriented programming languages—such as Java, Smalltalk, and C++—and conventional procedural programming languages—such as the "C" language or similar programming languages. The program code can be executed entirely on the operator's computer, partially on the operator's computer, as a standalone software package, partially on the operator's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the operator's computer via any type of network—including a local area network (LAN) or wide area network (WAN) that is compatible with medical network standards such as HL7 for HIS, RIS, and LIS systems—or it can be connected to an external computer (e.g., via the Internet using an Internet service provider). The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably.

[0091] Although preferred embodiments of the present application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present application.

[0092] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0093] The above provides a detailed description of the method and apparatus for batch location of encrypted buckets using hierarchical dynamic hashing. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, those skilled in the art will recognize that there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for batch locating encrypted buckets using hierarchical dynamic hashing, characterized in that, The method derives the positions of all candidate buckets on the same hash branch through a pointerless deterministic hierarchical hash mapping, and completes the location verification by acquiring all candidate bucket data at once through a batch prefetching mechanism, including the following steps: Obtain the basic dataset for locating encrypted buckets; Perform hierarchical hash mapping calculations on the basic dataset for locating the encrypted buckets to generate a set of candidate bucket row keys; Based on the candidate bucket row key set, perform batch reading and tag matching verification to generate candidate encrypted bucket matching results; The location of the target encrypted bucket is determined based on the candidate encrypted bucket matching results.

2. The method according to claim 1, characterized in that, The steps for obtaining the basic dataset for locating encrypted buckets include: Obtain the target access object to be located and its corresponding search key; Retrieve the preset hierarchical hash bucket size configuration parameters; The encrypted bucket location base dataset is generated using the target access object, the search key, and the hierarchical hash bucket size configuration parameters.

3. The method according to claim 2, characterized in that, The step of performing hierarchical hash mapping calculations based on the encrypted bucket location base dataset to generate a candidate bucket row key set includes: Based on the target access object and the search key, a cryptographic derivation is performed to obtain the complete internal tag; Based on the hierarchical hash bucket size configuration parameters and the complete internal label, a deterministic mapping calculation is performed to obtain the candidate bucket row keys corresponding to each level under the same hash branch; Summarize the candidate bucket row keys from all levels to generate a candidate bucket row key set.

4. The method according to claim 3, characterized in that, The step of performing hierarchical hash mapping calculations by locating the basic dataset through the encrypted bucket further includes: Based on preset incremental rules, set the bucket size values ​​corresponding to each level to generate a hierarchical bucket size sequence; By using the hierarchical bucket size sequence and complete internal labels, the candidate bucket row keys of each level on the same dynamic hash branch are derived sequentially.

5. The method according to claim 1, characterized in that, The step of performing batch reading and tag matching verification based on the candidate bucket row key set to generate candidate encrypted bucket matching results includes: Perform a batch prefetch database read on the candidate bucket row key set to obtain the candidate encrypted bucket data for all levels in one database interaction; The candidate encrypted bucket data is authenticated and decrypted. The identification information corresponding to the complete internal tag is matched in the decrypted bucket records to obtain the matching status of the candidate encrypted bucket. Based on the matching status, candidate encrypted bucket matching results are generated.

6. The method according to claim 1, characterized in that, The step of determining the location of the target encryption bucket based on the candidate encryption bucket matching results includes: The target access bucket is determined based on the candidate encrypted bucket matching results; The writable bucket is determined by the remaining storage space of the candidate encrypted packets; Based on the location information of the target access bucket and the writable bucket and the corresponding operation type, a target encrypted bucket location and operation decision result is generated.

7. The method according to claim 6, characterized in that, Also includes: In the data writing scenario, based on the target encrypted bucket location and operation decision results, a data update operation is performed on the target access bucket, a new data writing operation is performed on the writable bucket, or a new encrypted bucket of the corresponding level is created.

8. A hierarchical dynamic hashing encrypted bucket batch positioning device, characterized in that, The device implements the steps of the hierarchical dynamic hashing encrypted bucket batch location method as described in any one of claims 1-7: include: The acquisition module is used to acquire the basic dataset for locating encrypted buckets. The candidate bucket row key set module is used to perform hierarchical hash mapping calculations based on the encrypted bucket location base dataset to generate a candidate bucket row key set. The matching result module is used to perform batch reading and tag matching verification based on the candidate bucket row key set, and generate candidate encrypted bucket matching results; The target encryption bucket location module is used to determine the location of the target encryption bucket based on the candidate encryption bucket matching results.

9. A computer electronic device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein the computer program, when executed by the processor, implements the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, A computer program is stored on the computer-readable storage medium, which, when executed by a processor, implements the method as described in any one of claims 1 to 7.

Images