CN114238430B - True storage method and system based on verifiable steganone filter - Google Patents
True storage method and system based on verifiable steganone filter Download PDFInfo
- Publication number
- CN114238430B CN114238430B CN202111302206.6A CN202111302206A CN114238430B CN 114238430 B CN114238430 B CN 114238430B CN 202111302206 A CN202111302206 A CN 202111302206A CN 114238430 B CN114238430 B CN 114238430B
- Authority
- CN
- China
- Prior art keywords
- bloom filter
- data
- filter
- binary matrix
- random binary
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 72
- KHXMONVQVIGKEN-UHFFFAOYSA-N 6-O-alpha-L-(3''-O-isoferuloyl)rhamnopyranosylcatalpol Natural products C1=C2C=3C(OC)=C(OC)C(OC)=CC=3CC3C(=O)OCC3C(=O)C2=CC2=C1OCO2 KHXMONVQVIGKEN-UHFFFAOYSA-N 0.000 title claims abstract description 20
- KHXMONVQVIGKEN-KGLIPLIRSA-N steganone Chemical compound C1=C2C=3C(OC)=C(OC)C(OC)=CC=3C[C@H]3C(=O)OC[C@@H]3C(=O)C2=CC2=C1OCO2 KHXMONVQVIGKEN-KGLIPLIRSA-N 0.000 title claims abstract description 20
- 239000011159 matrix material Substances 0.000 claims abstract description 112
- 238000012795 verification Methods 0.000 claims abstract description 69
- 238000003672 processing method Methods 0.000 claims description 8
- 238000010276 construction Methods 0.000 claims description 5
- 238000013507 mapping Methods 0.000 claims description 3
- 241001263603 Stellera Species 0.000 claims 2
- 230000008569 process Effects 0.000 description 18
- 238000010586 diagram Methods 0.000 description 10
- 230000006870 function Effects 0.000 description 9
- 238000005516 engineering process Methods 0.000 description 8
- 238000004891 communication Methods 0.000 description 6
- QSHDDOUJBYECFT-UHFFFAOYSA-N mercury Chemical compound [Hg] QSHDDOUJBYECFT-UHFFFAOYSA-N 0.000 description 5
- 229910052753 mercury Inorganic materials 0.000 description 5
- 238000003491 array Methods 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000003780 insertion Methods 0.000 description 1
- 230000037431 insertion Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 238000011160 research Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2458—Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
- G06F16/2471—Distributed queries
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
- G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- General Health & Medical Sciences (AREA)
- Software Systems (AREA)
- Computer Hardware Design (AREA)
- Data Mining & Analysis (AREA)
- Medical Informatics (AREA)
- Fuzzy Systems (AREA)
- Mathematical Physics (AREA)
- Probability & Statistics with Applications (AREA)
- Computational Linguistics (AREA)
- Computing Systems (AREA)
- Storage Device Security (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The application provides a true storage method based on a verifiable secret bloom filter, which comprises the following steps: recording the raw data to an empty bloom filter; when the original data reach the preset capacity, constructing a random binary matrix with the same scale, and carrying out carry-free addition on the random binary matrix to obtain a steganone filter; respectively constructing a Merck tree by a stevenone filter and a random binary matrix according to rows and columns, and recording two tree roots and a hash mode of recorded data into a blockchain for evidence; receiving a verification request of a user, locally inquiring an acquisition result, acquiring corresponding rows and columns from a steganone filter and a random binary matrix, constructing a mercker proof and transmitting the mercker proof to a user side; and verifying the integrity of the rows in the hidden bloom filter and the columns in the random binary matrix at the user side, recovering the corresponding bits of the bloom filter, and judging whether the data is recorded in the bloom filter or not. The application obviously reduces the leaked private data under the condition of increasing a small amount of storage expenditure.
Description
Technical Field
The application relates to the technical field of verifiable storage, in particular to a real storage method and a system based on a verifiable secret bloom filter.
Background
Real storage technology based on block chain:
The real storage is to use the blockchain as a real storage platform, so that the data stored by the user are ensured to exist truly, cannot be tampered maliciously, and can also make a real response to the data access request of the user. In a real storage platform constructed based on the blockchain, users request operations such as adding, modifying, withdrawing and the like of data in a transaction form, and other users can read the content of the database according to the need and finish subsequent calculation work based on the data. In the whole flow of data access, auditability provided by the blockchain data layer ensures that a user can verify the integrity of the data when accessing the data; the decentralization characteristic provided by the block chain network layer can effectively avoid the problem of single-point failure; the consistency and non-tamper-resistance provided by the blockchain consensus layer ensures the authenticity of the user's access to the acquired data. Therefore, compared with a traditional centralized storage platform, the distributed real storage constructed based on the blockchain can stably run, and the problems of downtime, malicious tampering, data hiding, inconsistent access results provided for different users and the like of a central server are effectively avoided.
The current stage of the real storage technology based on the blockchain is mainly used in the fields of certification, collaborative databases and the like and used for ensuring the integrity of data, when a user challenges the integrity of the data, a verifier can provide certification under the chain, and the user can perform integrity verification by combining the evidence stored on the chain. The key technique for implementing real storage is to construct an authenticatable data structure (Authenticated Data Structure, ADS) designed for stored data, such as a relatively common merck tree in a blockchain, under which merck root is stored on the blockchain to ensure integrity, and when verifying a leaf node (i.e., single data), it proves that a hash value on a corresponding merck path and the merck root need to be sent to a verifier, and the verifier firstly queries the blockchain to confirm the integrity of the merck root and then verifies the integrity of data corresponding to the leaf node in combination with the merck path. In recent years, with the widespread use of blockchain technology, some researches have begun to explore new data structures to improve blockchain query efficiency, or enrich query structures, for which corresponding ADS structures need to be specifically designed in order to ensure verifiability of data.
Bloom filter:
Bloom Filters (BF) were proposed by Bloom in 1970. It is in effect a very long binary vector and a series of random mapping functions. Bloom filters may be used to retrieve whether an element is in a collection. Its advantages are high space efficiency and inquiry time, and high error recognition rate and deletion difficulty.
Bloom filters are an array of bits of length m that record data and query whether certain data exists. As shown in fig. 2, for a certain data, k hash functions are used to calculate the data to obtain k fields, each field can be mapped to a certain position in BF (Bloom Filter ) (the length of the BF is used to make a remainder), and when the data is inserted, only BF bits corresponding to the k fields need to be set to 1; when whether certain data exist or not is required to be inquired, k fields of the data are calculated through hashing by the same method, whether the corresponding k positions in BF are 1 or not is inquired, and if yes, the data are indicated to exist in the maximum probability; if any bit is 0, the data must not exist. BF has a certain error rate, but the error rate can be reduced to a very low level by adjusting the bloom filter length and the number of hash fields.
When constructing a BF for recording n pieces of data, the optimal choice of the size m and the number k of hash functions can be obtained by:
k＝ln(2)×(n/m)
the bloom filter error rates corresponding to the different values of k and n/m can be queried in fig. 3, wherein the second column in fig. 3 is the optimal design value of k, and k is usually the largest integer value smaller than the optimal value because k must be an integer in the practical application process.
Bloom filters can significantly reduce storage overhead and achieve query efficiency for O (1) complexity. Taking record 1G data as an example: if 6 hash functions are selected and the error rate is ensured not to exceed 1%, the bloom filter size is 10 gbit, namely 1.25GB; if the hash value of each data, i.e., 32B, is recorded without the bloom filter, the storage overhead is 32GB and the query overhead is at least O (log).
The bloom filter may be verified:
Bloom filters are widely used to record whether data exists, for example, in a Hash-based IP backtracking technique (Hash-Based IP Traceback, HBT), an intermediate node records the Hash value of a packet that has passed, backtracks the packet when a destination domain needs to query a packet forwarding path, sends a request to the intermediate node, and restores the true forwarding path of the packet according to the response. In order to reduce the storage overhead, it is a good strategy to record data packets using bloom filters
The specific flow of the IP backtracking technology HBT based on the hash is as follows:
(1) When the data packet passes through the intermediate router, the router samples the IP data packet, removes variable fields (e.g., TTL, checksum, etc.) of the packet header, and uses the unchanged fields (e.g., address fields, flag fields, etc.) of the packet header and the first eight bytes of the data portion of the data packet as a data digest.
(2) The data digest is hashed to obtain a 128-bit hash value, which is divided into 4 fields to obtain the corresponding 4 eigenvalues, and the bloom filter locations 1 to which they are mapped.
(3) When the destination end finds out a malicious message, tracing is started, and the transmission path of the data packet is obtained in a reverse flooding mode. After the victim node V detects the attack message, flooding a query request to a neighbor router of the victim node V, ignoring the request when the node does not store the message, continuing to flood the request to the neighbor when the node stores the message, and finally constructing a real forwarding path of the message and tracing the real forwarding path to the attack node.
However, in the above scheme, the integrity of the local bloom filter of the intermediate node cannot be ensured, that is, the bloom filter queried by the node is generated by the data packet recorded at the time, and has not been tampered. Therefore, the intermediate node hashes the bloom filter after locally recording data by a certain time interval to obtain the chain certificate is necessary. However, in such a form, the verifier would need to receive the entire bloom filter in order to verify the bloom filter integrity, not only causing significant communication overhead, but also revealing other packet privacy recorded therein.
In order to solve the problems of communication overhead, excessive revealing of privacy data and the like in the verification process, a simple method is to construct a merck tree by segments of a bloom filter, so that only segments corresponding to bits mapped by data characteristic values need to be returned for each verification, and the revealing privacy is obviously reduced. However, if the privacy protection is to be improved, the size of each segment needs to be reduced as much as possible, but the cost caused by constructing the merck tree is increased significantly, and in extreme cases, if the size of each segment is 1 bit, the storage cost caused by constructing the merck tree is 512 times that of the bloom filter; if the size of each segment is increased, the privacy data revealed by single verification is also increased significantly.
Disclosure of Invention
The present application aims to solve at least one of the technical problems in the related art to some extent.
Therefore, a first object of the present application is to provide a real storage method based on a verifiable secret bloom filter, which solves the technical problems of excessive communication overhead and excessive leakage of private data in the verification process of the conventional verifiable storage method of bloom filters, realizes that storage overhead and privacy protection are balanced while the verifiable bloom filter is constructed, and obviously reduces the leakage of private data under the condition of increasing a small amount of storage overhead, so as to effectively support the application of the verifiable bloom filter technology in the actual cooperation process.
The application uses binary matrix to construct Bloom Filter, for Bloom Filter (BF) with expected capacity of recorded data volume, a random binary matrix (Random binary matrix, RBM) is used to carry out non-carry addition to obtain hidden Bloom Filter (Hidden Bloom Filter, HBF); and then constructing the Mercury tree by the stevenone filter and the random two-mechanism matrix according to rows and columns respectively, and carrying out uplink certification on the hash of the tree root. Based on the method, when each data query and verification request is responded, the data query and verification request is only required to be sent to the most k rows in the user side secret bloom filter and the most k columns in the random binary matrix, and the most min { k 2, kl } bits in the bloom filter can only be acquired based on the received data at the user side, so that the data quantity leaked in single verification is reduced from kl to min { k 2, kl }, wherein l is the number of bits contained in each row in the bloom filter, and the number of leaked bits is obviously reduced. When the bloom filter size is greater than 128KB, the application can reduce data leakage by at least 99% without increasing storage overhead by more than two times. In addition, the size of the bloom filter rows and columns can be adjusted according to the service scene, so that the trade-off between privacy protection and the merck tree storage overhead is realized.
A second object of the present application is to propose a genuine storage system based on verifiable steganone filters.
To achieve the above objective, an embodiment of a first aspect of the present application provides a method for storing authenticity based on verifiable steganone filter, including: creating an empty bloom filter binary matrix and recording the raw data into the bloom filter; when the data recorded by the bloom filter reaches a preset capacity, constructing a random binary matrix with the same scale and carrying out carry-free addition on the random binary matrix, so as to obtain a stealth bloom filter; respectively constructing a Merck tree according to rows and columns by using a hidden bloom filter and a random binary matrix, and recording two tree roots and a hash mode when the bloom filter is used for recording data into a blockchain for evidence storage; receiving a verification request of a user, firstly inquiring an acquisition result locally, then acquiring corresponding rows and columns from a steganone filter and a random binary matrix, constructing a mercker proof and transmitting the mercker proof to a user side; and receiving the merck certification at the user terminal, verifying the integrity of the rows in the hidden bloom filter and the columns in the random binary matrix according to the certification and the merck root stored in the blockchain, recovering the corresponding bits of the bloom filter, and finally judging whether the data is recorded in the bloom filter.
Optionally, in an embodiment of the present application, for the structured bloom filter, the size of the bloom filter is first determined according to the usage method of the traditional bloom filter and the data volume and accuracy requirements, so as to set the number of rows and the number of columns of the bloom filter, where the specific values of the number of rows and the number of columns are set according to the actual privacy protection requirements, and several positions to which the record data in the bloom filter should be mapped are set to 1 for each record of data.
Optionally, in an embodiment of the present application, during the process of recording data to the bloom filter, the data to be recorded is hashed and a plurality of feature fields are obtained, then each feature field is mapped to a position in the bloom filter, where the position includes a corresponding row and a corresponding column, and finally the mapped position in the bloom filter is set to 1.
Optionally, in one embodiment of the present application, the random binary matrix is the same size as the bloom filter, and after the random binary matrix and the bloom filter are added in a non-carry manner, the obtained steganography filter also has the same size, where the size is the same for the number of rows, the number of columns, and the size.
Optionally, in one embodiment of the application, the stealth bloom filter constructs the merck tree in rows, each row acting as a leaf node of the merck tree; the random binary matrix constructs the merck tree according to columns, each column is used as a leaf node of the merck tree, after the construction is completed, two merck tree roots and hash modes corresponding to the bloom filter are put on the block chain, and the bloom filter, the random binary matrix and the stealth bloom filter are all stored locally.
Optionally, in one embodiment of the present application, for data that a user requests to query and verify, the data is hashed and several feature fields are obtained first and mapped to several positions in the bloom filter, if there is a position to which one feature field is mapped that is 0, it is determined that the data is not recorded in the bloom filter, then the result is returned, and no proof exists in the construction; if all the feature fields are mapped to positions of 1, determining that the data is recorded in a bloom filter, returning the result, and constructing a presence certificate, wherein the hash mode of the data for requesting query and verification and the original data is the same.
Optionally, in one embodiment of the application, when the user receives a reply of "no present," the blockchain is queried first to confirm that the integrity of two merck roots in the proof does not exist; secondly, verifying the integrity of rows in the hidden bloom filter and columns in the random binary matrix by combining with the mercer path; then, the queried data is processed by the same processing method as the original data to obtain a plurality of positions in the corresponding bloom filter, and whether the 0 bit returned by the data recorder is one of the positions is judged; finally, carry out carry-free addition by using the bit number in the steganone filter corresponding to the 0 bit and the bit number in the random binary matrix, and judging whether the obtained result is 0: if 0 and the previous verification is passed, the query result is believed to be the same; if not 0, or any of the previous verifications failed, the reply is not believed.
Optionally, in one embodiment of the application, when the user receives a reply of "present," the blockchain is queried first to confirm the integrity of the two merck roots in the presence certificate; secondly, respectively verifying the integrity of each row in the stevenone filter and each column in the random binary matrix by combining the merck paths contained in the two merck roots; then, the queried data is processed by the same processing method as the original data to obtain a plurality of positions in the corresponding bloom filter, and whether the generated characteristic field corresponds to the plurality of positions is judged; and finally, sequentially carrying out non-carry addition by using the digits in the steganone filters corresponding to a plurality of positions and the digits in the random binary matrix, and judging the obtained result: if the carry-out addition results are all 1 and the previous verification is passed, then it is believed that this reply; if there is any carry-out addition result that is not 1, or any verification before is not passed, then the reply is not believed.
To achieve the above object, an embodiment of a second aspect of the present application provides a verifiable stevenone filter-based real storage system, including: a data recording side, a verification side, wherein,
A data logger for creating an empty bloom filter binary matrix and recording data into the bloom filter; when the data recorded by the bloom filter reaches a preset capacity, constructing a random binary matrix with the same scale and carrying out carry-free addition on the random binary matrix, so as to obtain a stealth bloom filter; respectively constructing a Merck tree according to rows and columns by using a hidden bloom filter and a random binary matrix, and recording two tree roots and a hash mode when the bloom filter is used for recording data into a blockchain for evidence storage;
The data recording party is also used for receiving the verification request sent by the verification party, firstly inquiring the obtained result locally, then obtaining corresponding rows and columns from the steganone filter and the random binary matrix, constructing a merck certificate and sending the merck certificate to the verification party;
The verifying party is also used for receiving the merck certification, then verifying the integrity of the rows in the hidden bloom filter and the columns in the random binary matrix according to the received certification and the merck root stored in the block chain, then recovering the corresponding bits of the bloom filter, and finally judging whether the data is recorded in the bloom filter.
The real storage method and the real storage system based on the verifiable secret bloom filter solve the technical problems of excessive communication expenditure and excessive privacy data leakage in the verification process of the verifiable storage method of the traditional bloom filter, realize the balance of storage expenditure and privacy protection while constructing the verifiable bloom filter, and obviously reduce the leaked privacy data under the condition of increasing a small amount of storage expenditure, thereby effectively supporting the application of the verifiable bloom filter technology in the actual cooperation process.
The application uses binary matrix to construct Bloom Filter, for Bloom Filter (BF) with expected capacity of recorded data volume, a random binary matrix (Random binary matrix, RBM) is used to carry out non-carry addition to obtain hidden Bloom Filter (Hidden Bloom Filter, HBF); and then constructing the Mercury tree by the stevenone filter and the random two-mechanism matrix according to rows and columns respectively, and carrying out uplink certification on the hash of the tree root. Based on the method, when each data query and verification request is responded, the data query and verification request is only required to be sent to the most k rows in the user side secret bloom filter and the most k columns in the random binary matrix, and the most min { k 2, kl } bits in the bloom filter can only be acquired based on the received data at the user side, so that the data quantity leaked in single verification is reduced from kl to min { k 2, kl }, wherein l is the number of bits contained in each row in the bloom filter, and the number of leaked bits is obviously reduced. When the bloom filter size is greater than 128KB, the application can reduce data leakage by at least 99% without increasing storage overhead by more than two times. In addition, the size of the bloom filter rows and columns can be adjusted according to the service scene, so that the trade-off between privacy protection and the merck tree storage overhead is realized.
Additional aspects and advantages of the application will be set forth in part in the description which follows and, in part, will be obvious from the description, or may be learned by practice of the application.
Drawings
The foregoing and/or additional aspects and advantages of the application will become apparent and readily appreciated from the following description of the embodiments, taken in conjunction with the accompanying drawings, in which:
FIG. 1 is a flow chart of a method for storing authenticity based on a verifiable stevenone filter according to a first embodiment of the present application;
FIG. 2 is a schematic diagram of data insertion and query operations of a bloom filter in accordance with an embodiment of the present application;
FIG. 3 is a schematic diagram of bloom filter parameters according to an embodiment of the present application;
FIG. 4 is another flow chart of a verifiable stevenone filter-based real storage method according to an embodiment of the application;
FIG. 5 is a schematic diagram of a bloom filter based on a verifiable covert bloom filter real storage method in accordance with an embodiment of the present application;
FIG. 6 is a schematic flow chart of acquiring data characteristic values based on a verifiable stevenone filter true storage method according to an embodiment of the application;
FIG. 7 is a schematic diagram of a verification-based method for storing a verification-based stevenone filter according to an embodiment of the present application;
FIG. 8 is a schematic diagram of a Merck tree of a verifiable stevenone filter-based real storage method according to an embodiment of the present application;
FIG. 9 is a schematic flow chart of a recovering original Mercury tree of a real storage method based on a verifiable steganone filter according to an embodiment of the present application;
fig. 10 is a schematic diagram of a real storage system based on a verifiable stevenone filter according to a second embodiment of the present application.
Detailed Description
Embodiments of the present application are described in detail below, examples of which are illustrated in the accompanying drawings, wherein like or similar reference numerals refer to like or similar elements or elements having like or similar functions throughout. The embodiments described below by referring to the drawings are illustrative and intended to explain the present application and should not be construed as limiting the application.
The following describes a verifiable stevenone filter-based real storage method and system according to an embodiment of the present application with reference to the accompanying drawings.
Fig. 1 is a flowchart of a real storage method based on a verifiable stevenone filter according to an embodiment of the present application.
As shown in fig. 1, the verifiable stevenone filter-based real storage method comprises the following steps:
step 101, creating an empty bloom filter binary matrix and recording the original data into the bloom filter;
102, when the data recorded by the bloom filter reaches a preset capacity, constructing a random binary matrix with the same scale and carrying out carry-out addition with the random binary matrix to obtain a stealth bloom filter;
Step 103, constructing a merck tree according to rows and columns respectively by using a stevenone filter and a random binary matrix, and recording two tree roots and a hash mode when the data are recorded by using the stevenone filter into a blockchain for evidence storage;
Step 104, receiving a verification request of a user, firstly inquiring the obtained result locally, then obtaining corresponding rows and columns from a steganone filter and a random binary matrix, constructing a merck certificate and sending the merck certificate to a user side;
Step 105, receiving the merck certification at the user terminal, then verifying the integrity of the rows in the hidden bloom filter and the columns in the random binary matrix according to the received certification and the merck root stored in the blockchain, then recovering the corresponding bits of the bloom filter, and finally judging whether the data is recorded in the bloom filter.
The real storage method based on the verifiable secret bloom filter in the embodiment of the application is characterized by creating an empty bloom filter binary matrix and recording original data into the bloom filter; when the data recorded by the bloom filter reaches a preset capacity, constructing a random binary matrix with the same scale and carrying out carry-free addition on the random binary matrix, so as to obtain a stealth bloom filter; respectively constructing a Merck tree according to rows and columns by using a hidden bloom filter and a random binary matrix, and recording two tree roots and a hash mode when the bloom filter is used for recording data into a blockchain for evidence storage; receiving a verification request of a user, firstly inquiring an acquisition result locally, then acquiring corresponding rows and columns from a steganone filter and a random binary matrix, constructing a mercker proof and transmitting the mercker proof to a user side; and receiving the merck certification at the user terminal, verifying the integrity of the rows in the hidden bloom filter and the columns in the random binary matrix according to the certification and the merck root stored in the blockchain, recovering the corresponding bits of the bloom filter, and finally judging whether the data is recorded in the bloom filter. Therefore, the technical problems of excessive communication cost and excessive leakage of privacy data in the verification process of the verifiable storage method of the traditional bloom filter can be solved, the storage cost and privacy protection are weighed while the verifiable bloom filter is built, and the leakage of the privacy data is obviously reduced under the condition of increasing a small amount of storage cost, so that the application of the verifiable bloom filter technology in the actual cooperation process is effectively supported.
The application uses binary matrix to construct Bloom Filter, for Bloom Filter (BF) with expected capacity of recorded data volume, a random binary matrix (Random binary matrix, RBM) is used to carry out non-carry addition to obtain hidden Bloom Filter (Hidden Bloom Filter, HBF); and then constructing the Mercury tree by the stevenone filter and the random two-mechanism matrix according to rows and columns respectively, and carrying out uplink certification on the hash of the tree root. Based on the method, when each data query and verification request is responded, the data query and verification request is only required to be sent to the most k rows in the user side secret bloom filter and the most k columns in the random binary matrix, and the most min { k 2, kl } bits in the bloom filter can only be acquired based on the received data at the user side, so that the data quantity leaked in single verification is reduced from kl to min { k 2, kl }, wherein l is the number of bits contained in each row in the bloom filter, and the number of leaked bits is obviously reduced. When the bloom filter size is greater than 128KB, the application can reduce data leakage by at least 99% without increasing storage overhead by more than two times. In addition, the size of the bloom filter rows and columns can be adjusted according to the service scene, so that the trade-off between privacy protection and the merck tree storage overhead is realized.
Each bloom filter generates a matched random number, and when the characteristic field of the recorded data is generated, the data needs to be hashed after being combined with the random number. Each random number is not disclosed outwards in the use process of the corresponding bloom filter, and when the bloom filter finishes recording (namely, the preset data quantity is recorded) and is linked, the matched random number is disclosed in a linking way, so that the situation that certain specified unrecorded data is wrongly considered to be recorded in the bloom filter due to targeted manufacturing data of an attacker is avoided. In addition, in order to reduce the hash times, when the characteristic field is generated, the data is hashed once and then divided into k sections, so that k characteristic values are obtained; if the hash length obtained by one hash is not enough to be divided into k segments, a plurality of matched random numbers can be generated for the bloom filter, a plurality of corresponding hash values are generated for each recorded data, and then the hash values are divided into k segments.
Further, in the embodiment of the present application, for the structured bloom filter, firstly, according to the usage method of the traditional bloom filter, the size of the bloom filter is determined according to the data volume and accuracy requirements, and then the number of rows and the number of columns of the bloom filter are set, the specific values of the number of rows and the number of columns are set according to the actual privacy protection requirements, and each record of one piece of data needs to be set to 1 at a plurality of positions to which the record data in the bloom filter is mapped.
For the bloom filter with the structure, the number of rows is s, the number of columns is l, the total size is m=sl, k bits in the bloom filter are required to be set to be 1 for each piece of recorded data, and the upper limit of the data capacity which can be recorded by the bloom filter is n, so that the selection of m and k can be selected according to different error rate expectations and the requirement of n with reference to fig. 3.
Further, in the embodiment of the present application, during the process of recording data to the bloom filter, the data to be recorded is hashed first and a plurality of feature fields are obtained, then each feature field is mapped to a position in the bloom filter, the position includes a corresponding row and a corresponding column, and finally the mapped position in the bloom filter is set to 1.
In the process of recording data to the bloom filter, firstly, the data to be recorded is hashed and k characteristic fields are obtained, C i represents the ith characteristic field (the corresponding hash mode of each bloom filter is different, the specific hash mode is disclosed in the bloom filter certification process), then each characteristic field C i is mapped to a position BF [ x i][yi ] in the bloom filter BF, the corresponding row x i is (C i/' l)% s, the corresponding column y i is C i% l, and finally the k bit in the bloom filter is set to 1.
Further, in the embodiment of the application, the scale of the random binary matrix is the same as that of the bloom filter, and after the random binary matrix and the bloom filter are added in a non-carry way, the obtained steganography filter also has the same scale, wherein the scale is the same in number of rows, number of columns and size.
The random binary matrix has the same scale as the bloom filter, the number of rows is s, the number of columns is l, and the total size is m=sl. After the random binary matrix and the bloom filter are added in a non-carry way, the obtained steganography filter also has the same scale, namely the number of rows is s, the number of columns is l, and the total size is m=sl.
Further, in the embodiment of the application, the stevenone filter constructs the merck tree according to rows, and each row is used as a leaf node of the merck tree, and the length is l; the random binary matrix constructs the merck tree according to columns, each column is used as a leaf node of the merck tree, the length is s, after the construction, the hash modes corresponding to two merck tree roots and the bloom filter are put on the blockchain (the blockchain can be any existing public chain or alliance chain), and the bloom filter, the random binary matrix and the stealth bloom filter are all stored locally.
Further, in the embodiment of the present application, for the data that the user requests to query and verify, firstly, hash the data and obtain a plurality of feature fields, and map the feature fields to a plurality of positions in the bloom filter, if there is a position mapped to by one feature field being 0, it is determined that the data is not recorded in the bloom filter, then the result is returned, and no proof exists in the construction; if all the feature fields are mapped to positions of 1, determining that the data is recorded in a bloom filter, returning the result, and constructing a presence certificate, wherein the hash mode of the data for requesting query and verification and the original data is the same.
For Data that a user requests to query and verify, the Data logger hashes and obtains k feature fields by creating an empty bloom filter binary matrix to record the Data into the bloom filter and maps them to k positions in the bloom filter, if there is a position BF [ x v][yv ] mapped by a feature field c v of 0, it means that the Data is not recorded in the bloom filter, then the result is returned, and no proof P N is constructed, the format of which is as follows:
PN：＝{HBF[xv][：],RBM[：][yv],MKP1,MKP2,MKR1,MKR2}
Wherein, HBF [ x v ] [: and is line x v of the steganone filter HBF, RBM [: [ y v ] is the y v th column of the random binary matrix RBM, MKP 1 and MKP 2 are used to verify HBF [ x v ] respectively: and RBM [ ]. The merck path of [ y v ], MKR 1 and MKR 2 are the corresponding merck roots.
If the position BF [ x i][yi ] to which all the feature fields are mapped is 1 for the Data, it is explained that the Data is recorded in the bloom filter, and then the result is returned, and the presence certificate P Y is constructed in the format as follows:
PY：＝{HBF[x1：xk][：],RBM[：][y1：yk],MKP1,MKP2,MKR1,MKR2}
Wherein, HBF [ x 1：xk ] [: and is k rows in the steganone filter HBF, RBM [: [ y 1：yk ] is the k columns of the random binary matrix RBM, x i and y i are the row and column numbers corresponding to the bloom filter position mapped to the eigenvalue c i of the DATA DATA, MKP 1 and MKP 2 are the column numbers respectively containing verification HBF [ x 1：xk ]: and RBM [ ]. The merck path of [ y 1：yk ], MKR 1 and MKR 2 are the corresponding merck roots.
Further, in the embodiment of the present application, when the user receives a reply of "no present", the blockchain is queried first to confirm that the integrity of the two merck roots MKR 1 and MKR 2 in P N is not present; second, verify hidden bloom filter row HBF [ x v ] [ in combination with mercker paths MKP 1 and MKP 2: and a column RBM in the random binary matrix [: integrity of [ y v ]; then, the queried data is processed by the same processing method as the original data to obtain k positions in the corresponding bloom filter, and whether (x v,yv) is one of the positions is judged; finally, HBF [ x v ] [ is used: in [ ] position y v and RBM [: carry out carry-out addition at the x v th bit in [ y v ], and judge the obtained result: if 0 and the previous verification is passed, the query result is believed to be the same; if not 0, or any of the previous verifications failed, the reply is not believed.
Further, in the embodiment of the present application, when the user receives a reply of "present", the blockchain is queried first to confirm the integrity of the two merck roots MKR 1 and MKR 2 in the presence certificate P Y; secondly, respectively verifying the integrity of each row in the stevenone filter and each column in the random binary matrix by combining the merck paths contained in the two merck roots; then, the queried data is processed by the same processing method as the original data to obtain k positions in the corresponding bloom filter, and whether the generated characteristic field (x 1,y1),(x2,y2),…,(xk,yk) corresponds to the k positions is judged; finally, HBF [ x i ] [ is used in sequence: y i th bit and RBM [ ]: carrying out carry-free addition on the x i bit in the [ y i ] to obtain k bits, and judging the obtained result: if the k bits are all 1's and the previous verification passed, then the reply is believed; if there is any bit of 0, or if any of the previous verifications did not pass, then this reply is not believed.
Fig. 4 is another flowchart of a verifiable stevenone filter-based real storage method according to an embodiment of the present application.
As shown in fig. 4, in the verifiable steganographic filter-based real storage method, a data logger creates an empty bloom filter binary matrix and records data into the bloom filter; when the data recorded by the bloom filter reaches a preset capacity, the data recording party constructs a random binary matrix with the same scale and carries out carry-free addition with the random binary matrix, so as to obtain a secret bloom filter; the data recorder constructs the Merck tree by the hidden bloom filter according to the rows, constructs the Merck tree by the random binary matrix according to the columns, and records two tree roots and a hash mode when the bloom filter is used for recording data into a blockchain for evidence storage; aiming at a verification request of a user, a data recording party firstly inquires an acquisition result locally, then acquires corresponding rows and columns from a steganone filter and a random binary matrix, constructs a merck certificate and sends the merck certificate to the user; the user verifies the integrity of the rows in the hidden bloom filter and the columns in the random binary matrix according to the received evidence and the merck root stored in the blockchain, then recovers the corresponding bits of the original bloom filter, and finally judges whether the data is recorded in the original bloom filter.
Fig. 5 is a schematic diagram of a bloom filter based on a verifiable covert bloom filter for a real storage method according to an embodiment of the present application.
As shown in fig. 5, the bloom filter based on the verifiable secret bloom filter real storage method has the row number s, the column number l, and the total size m=slbit.
Fig. 6 is a schematic flow chart of acquiring data characteristic values based on a verifiable stevenone filter real storage method according to an embodiment of the application.
As shown in fig. 6, the real storage method based on the verifiable stevenone filter can obtain a 32-byte hash value by combining a data with a random number r, considering that the feature value is mapped to one bit in the stevenone filter, the length of the feature value must be greater than or equal to log 2 m, so that the feature value length can be determined according to the actual service requirement, and if one hash value is insufficient to meet the length requirement of k feature values, multiple random numbers can be generated for each of the stevenone filters, and multiple hash values can be respectively generated by combining the hash values with the data. The signature field length considered in fig. 5 is 8 bytes, i.e. 64 bits, sufficient to meet all bloom filter requirements of no more than 2 64 bits in size, at which time a hash value can be split into 4 signature values.
Fig. 7 is a schematic diagram of a verifiable stevenone filter calculation based on a real storage method of the verifiable stevenone filter in an embodiment of the application.
As shown in fig. 7, in the real storage method based on the verifiable secret bloom filter, the data logger first constructs a random binary matrix with the same scale as the bloom filter, the number of rows being s, the number of columns being l, and the total size being m=sl. After the bloom filter gauge and the random binary matrix are added in a non-carry way, the obtained steganography filter also has the same scale, namely the number of rows is s, the number of columns is l, and the total size is m=sl.
Fig. 8 is a schematic diagram of a merck tree of a real storage method based on a verifiable stevenone filter according to an embodiment of the present application.
As shown in fig. 8, the merck tree of the real storage method based on the verifiable stevenone filter is constructed by the stevenone filter with the number of lines of 8, and the hash value of each line is combined with the corresponding line number to be used as a leaf node of the merck tree, namely: hashi =i||H (HBF [ i ]:), and the intermediate node is the hash of the combination of hash values corresponding to the left child node and the right child node of the intermediate node, so that a merck root can be obtained finally. When the corresponding line number and the merck proof are returned to the user, assuming that the 1 st line is returned, the corresponding merck path is:
{1，Hash0，H(Hash2||Hash3)，H(H(Hash4||Hash5)||H(Hash6||Hash7))，MKR}
After receiving the merck path and the first line of the hidden bloom filter, the user firstly combines and hashes the line number 1 and the line of the hidden bloom filter to obtain Hash1, then combines and hashes the Hash1 and the Hash0 to obtain H (Hash 0I Hash 1), gradually combines and hashes to obtain a merck root MKR', judges whether the calculated merck root is the same as MKR or not, and judges whether MKR is in the previous recorded blockchain or not, and if verification is passed, the integrity verification of the first line of the hidden bloom filter is completed.
Fig. 9 is a schematic flow chart of a recovering original merck tree of a real storage method based on a verifiable stevenone filter according to an embodiment of the present application.
As shown in fig. 9, it is assumed here that the number of eigenvalues generated by each data when recorded to the bloom filter is k=4, and the bits mapped to the original bloom filter are respectively: BF [ i 1][j1],BF[i2][j2],BF[i3][j3 ] and BF [ i 4][j4 ]. Thus, the 4 rows of steganographic filters and 4 columns of random binary matrices corresponding to the verifier are returned by the data logger as follows:
{(HBF[i1][：],RBM[：][j1]),(HBF[i2][：],RBM[：][j2])，
(HBF[i3][：],RBM[：][j3]),(HBF[i4][：],RBM[：][j4])}
After the verifier verifies the integrity of the data based on the merck path and the certification record on the chain and determines the row number, 4 characteristic values are obtained by hashing the verification data with the random numbers stored on the chain and mapped to 4 bits in the bloom filter, the row numbers are (i '1,j′1),(i′2,j′2),(i′3,j′3) and (i' 4,j′4) respectively, and after the verification is passed by comparing with the row number obtained in the previous verification process, 4 bits corresponding to the bloom filter are restored. Taking the recovery of the first bit as an example, HBF [ i 1 ] [ is used: bits j 1 and RBM [: the first bit can be obtained by adding the i 1 bit of the [ j 1 ], and after 4 bits are recovered, if the first bit is 1, the verified data can be judged to be recorded in a bloom filter with high probability; if any bit is 0, the verified data must not be in the bloom filter. In the figure, white represents successfully recovered bits, black represents leaked privacy bits, and the total number of bits leaked in a single verification can be judged to be not more than k 2, wherein the privacy bits are not more than k (k-1).
Fig. 10 is a schematic diagram of a real storage system based on a verifiable stevenone filter according to a second embodiment of the present application.
As shown in fig. 10, the verifiable steganographic filter-based real storage system includes: a data recording side, a verification side, wherein,
A data logger for creating an empty bloom filter binary matrix and recording data into the bloom filter; when the data recorded by the bloom filter reaches a preset capacity, constructing a random binary matrix with the same scale and carrying out carry-free addition on the random binary matrix, so as to obtain a stealth bloom filter; respectively constructing a Merck tree according to rows and columns by using a hidden bloom filter and a random binary matrix, and recording two tree roots and a hash mode when the bloom filter is used for recording data into a blockchain for evidence storage;
The data recording party is also used for receiving the verification request sent by the verification party, firstly inquiring the obtained result locally, then obtaining corresponding rows and columns from the steganone filter and the random binary matrix, constructing a merck certificate and sending the merck certificate to the verification party;
The verifying party is also used for receiving the merck certification, then verifying the integrity of the rows in the hidden bloom filter and the columns in the random binary matrix according to the received certification and the merck root stored in the block chain, then recovering the corresponding bits of the bloom filter, and finally judging whether the data is recorded in the bloom filter.
The embodiment of the application discloses a real storage system based on a verifiable secret bloom filter, which comprises a data recording party and a verifying party, wherein the data recording party is used for creating an empty bloom filter binary matrix and recording data into the bloom filter; when the data recorded by the bloom filter reaches a preset capacity, constructing a random binary matrix with the same scale and carrying out carry-free addition on the random binary matrix, so as to obtain a stealth bloom filter; respectively constructing a Merck tree according to rows and columns by using a hidden bloom filter and a random binary matrix, and recording two tree roots and a hash mode when the bloom filter is used for recording data into a blockchain for evidence storage; the data recording party is also used for receiving the verification request sent by the verification party, firstly inquiring the obtained result locally, then obtaining corresponding rows and columns from the steganone filter and the random binary matrix, constructing a merck certificate and sending the merck certificate to the verification party; the verifying party is also used for receiving the merck certification, then verifying the integrity of the rows in the hidden bloom filter and the columns in the random binary matrix according to the received certification and the merck root stored in the block chain, then recovering the corresponding bits of the bloom filter, and finally judging whether the data is recorded in the bloom filter. Therefore, the technical problems of excessive communication cost and excessive leakage of privacy data in the verification process of the verifiable storage method of the traditional bloom filter can be solved, the storage cost and privacy protection are weighed while the verifiable bloom filter is built, and the leakage of the privacy data is obviously reduced under the condition of increasing a small amount of storage cost, so that the application of the verifiable bloom filter technology in the actual cooperation process is effectively supported.
The application uses binary matrix to construct Bloom Filter, for Bloom Filter (BF) with expected capacity of recorded data volume, a random binary matrix (Random binary matrix, RBM) is used to carry out non-carry addition to obtain hidden Bloom Filter (Hidden Bloom Filter, HBF); and then constructing the Mercury tree by the stevenone filter and the random two-mechanism matrix according to rows and columns respectively, and carrying out uplink certification on the hash of the tree root. Based on the method, when each data query and verification request is responded, the data query and verification request is only required to be sent to the most k rows in the user side secret bloom filter and the most k columns in the random binary matrix, and the most min { k 2, kl } bits in the bloom filter can only be acquired based on the received data at the user side, so that the data quantity leaked in single verification is reduced from kl to min { k 2, kl }, wherein l is the number of bits contained in each row in the bloom filter, and the number of leaked bits is obviously reduced. When the bloom filter size is greater than 128KB, the application can reduce data leakage by at least 99% without increasing storage overhead by more than two times. In addition, the size of the bloom filter rows and columns can be adjusted according to the service scene, so that the trade-off between privacy protection and the merck tree storage overhead is realized.
In the description of the present specification, a description referring to terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the present application. In this specification, schematic representations of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, the different embodiments or examples described in this specification and the features of the different embodiments or examples may be combined and combined by those skilled in the art without contradiction.
Furthermore, the terms "first," "second," and the like, are used for descriptive purposes only and are not to be construed as indicating or implying a relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defining "a first" or "a second" may explicitly or implicitly include at least one such feature. In the description of the present application, the meaning of "plurality" means at least two, for example, two, three, etc., unless specifically defined otherwise.
Any process or method descriptions in flow charts or otherwise described herein may be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps of the process, and additional implementations are included within the scope of the preferred embodiment of the present application in which functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order from that shown or discussed, depending on the functionality involved, as would be understood by those reasonably skilled in the art of the embodiments of the present application.
Logic and/or steps represented in the flowcharts or otherwise described herein, e.g., a ordered listing of executable instructions for implementing logical functions, can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. For the purposes of this description, a "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of the computer-readable medium would include the following: an electrical connection (electronic device) having one or more wires, a portable computer diskette (magnetic device), a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber device, and a portable compact disc read-only memory (CDROM). In addition, the computer readable medium may even be paper or other suitable medium on which the program is printed, as the program may be electronically captured, via, for instance, optical scanning of the paper or other medium, then compiled, interpreted or otherwise processed in a suitable manner, if necessary, and then stored in a computer memory.
It is to be understood that portions of the present application may be implemented in hardware, software, firmware, or a combination thereof. In the above-described embodiments, the various steps or methods may be implemented in software or firmware stored in a memory and executed by a suitable instruction execution system. As with the other embodiments, if implemented in hardware, may be implemented using any one or combination of the following techniques, as is well known in the art: discrete logic circuits having logic gates for implementing logic functions on data signals, application specific integrated circuits having suitable combinational logic gates, programmable Gate Arrays (PGAs), field Programmable Gate Arrays (FPGAs), and the like.
Those of ordinary skill in the art will appreciate that all or a portion of the steps carried out in the method of the above-described embodiments may be implemented by a program to instruct related hardware, where the program may be stored in a computer readable storage medium, and where the program, when executed, includes one or a combination of the steps of the method embodiments.
In addition, each functional unit in the embodiments of the present application may be integrated in one processing module, or each unit may exist alone physically, or two or more units may be integrated in one module. The integrated modules may be implemented in hardware or in software functional modules. The integrated modules may also be stored in a computer readable storage medium if implemented in the form of software functional modules and sold or used as a stand-alone product.
The above-mentioned storage medium may be a read-only memory, a magnetic disk or an optical disk, or the like. While embodiments of the present application have been shown and described above, it will be understood that the above embodiments are illustrative and not to be construed as limiting the application, and that variations, modifications, alternatives and variations may be made to the above embodiments by one of ordinary skill in the art within the scope of the application.
Claims (6)
1. The true storage method based on the verifiable stevenone filter is characterized by comprising the following steps of:
creating an empty bloom filter binary matrix and recording the raw data into the bloom filter;
When the data recorded by the bloom filter reaches a preset capacity, constructing a random binary matrix with the same scale and carrying out carry-free addition on the random binary matrix, so as to obtain a stealth bloom filter;
respectively constructing the Merck tree according to rows and columns by the stellera filter and the random binary matrix, and recording two tree roots and a hash mode when the data are recorded by using the bloom filter into a blockchain for evidence storage;
Receiving a verification request of a user, firstly inquiring an acquisition result locally, then acquiring corresponding rows and columns from a steganone filter and a random binary matrix, constructing a mercker proof and transmitting the mercker proof to a user side;
receiving the merck evidence at the user terminal, verifying the integrity of rows in the hidden bloom filter and columns in the random binary matrix according to the received evidence and the merck tree root stored in the blockchain, recovering corresponding bits of the bloom filter, and finally judging whether the data is recorded in the bloom filter;
For data which is requested to be queried and verified by a user, firstly, hashing the data and obtaining a plurality of characteristic fields, mapping the characteristic fields to a plurality of positions in a bloom filter, if the position mapped by one characteristic field is 0, determining that the data is not recorded in the bloom filter, returning the result, and constructing that no evidence exists; if the positions mapped by all the characteristic fields are 1, determining that the data is recorded in a bloom filter, returning the result, and constructing a presence certificate, wherein the hash mode of the data for requesting query and verification and the original data is the same;
when the user receives the reply of 'no exist', firstly querying the blockchain to confirm the integrity of two merck tree roots in the no-exist evidence; secondly, verifying the integrity of rows in the hidden bloom filter and columns in the random binary matrix by combining with the mercer path; then, the queried data is processed by the same processing method as the original data to obtain a plurality of positions in the corresponding bloom filter, and whether the 0 bit returned by the data recorder is one of the positions is judged; finally, carrying out non-carry addition by using the bit number in the stevenone filter corresponding to the 0 bit and the bit number in the random binary matrix, judging whether the obtained result is 0, if 0, and the previous verification is passed, believing that the query result is the query result, and if not 0, or if any previous verification fails, not believing the reply;
When the user receives the reply of 'present', firstly querying the blockchain to confirm the integrity of two merck tree roots in the presence certificate; secondly, respectively verifying the integrity of each row in the hidden bloom filter and each column in the random binary matrix by combining the mercer paths contained in the two mercer tree roots; then, the queried data is processed by the same processing method as the original data to obtain a plurality of positions in the corresponding bloom filter, and whether the generated characteristic field corresponds to the plurality of positions is judged; and finally, carrying out carry-free addition by using the digits in the corresponding stegand bloom filters and the digits in the random binary matrix, judging the obtained result, if the carry-free addition results are all 1 and the previous verification is passed, believing the reply, and if any carry-free addition result is not 1 or the previous verification is not passed, not believing the reply.
2. The method of claim 1, wherein for the structured bloom filter, the size of the bloom filter is first determined according to the usage method of the traditional bloom filter and the data amount and accuracy requirement, so as to set the number of rows and columns of the bloom filter, the specific values of the number of rows and the number of columns are set according to the actual privacy protection requirement, and a plurality of positions to which recorded data in the bloom filter is mapped are set to 1 for each piece of recorded data.
3. A method as claimed in claim 2, characterized in that during the recording of the data to the bloom filter, the data to be recorded is hashed and several feature fields are obtained, each feature field is then mapped to a position in the bloom filter, which position comprises a corresponding row and a corresponding column, and finally the mapped position in the bloom filter is set to 1.
4. The method of claim 1, wherein the random binary matrix is the same size as the bloom filter, and the resulting stevenone filter is the same size after the random binary matrix and the bloom filter are added in a non-carry manner, wherein the same size means the same number of rows, the same number of columns, and the same size.
5. The method of claim 1, wherein the stealth bloom filter constructs a mercer tree in rows, each row serving as a leaf node of the mercer tree; the random binary matrix constructs the merck tree according to columns, each column is used as a leaf node of the merck tree, after the construction is completed, two merck tree roots and hash modes corresponding to a bloom filter are put on a block chain, and the bloom filter, the random binary matrix and the hidden bloom filter are all stored locally.
6. A true storage system based on a verifiable stevenone filter is characterized by comprising a data recording party and a verifying party, wherein,
The data recorder is used for creating an empty bloom filter binary matrix and recording the original data into the bloom filter; when the data recorded by the bloom filter reaches a preset capacity, constructing a random binary matrix with the same scale and carrying out carry-free addition on the random binary matrix, so as to obtain a stealth bloom filter; respectively constructing the Merck tree according to rows and columns by the stellera filter and the random binary matrix, and recording two tree roots and a hash mode when the data are recorded by using the bloom filter into a blockchain for evidence storage;
The data recording party is also used for receiving the verification request sent by the verification party, firstly inquiring the obtained result locally, then obtaining corresponding rows and columns from the steganone filter and the random binary matrix, constructing the merck certificate and sending the merck certificate to the verification party;
The verifier is also used for receiving the mercuric evidence, verifying the integrity of rows in the hidden bloom filter and columns in the random binary matrix according to the received evidence and the mercuric tree root stored in the blockchain, recovering the corresponding bit of the bloom filter, and finally judging whether the data is recorded in the bloom filter;
For data which is requested to be queried and verified by a user, firstly, hashing the data and obtaining a plurality of characteristic fields, mapping the characteristic fields to a plurality of positions in a bloom filter, if the position mapped by one characteristic field is 0, determining that the data is not recorded in the bloom filter, returning the result, and constructing that no evidence exists; if the positions mapped by all the characteristic fields are 1, determining that the data is recorded in a bloom filter, returning the result, and constructing a presence certificate, wherein the hash mode of the data for requesting query and verification and the original data is the same;
when the user receives the reply of 'no exist', firstly querying the blockchain to confirm the integrity of two merck tree roots in the no-exist evidence; secondly, verifying the integrity of rows in the hidden bloom filter and columns in the random binary matrix by combining with the mercer path; then, the queried data is processed by the same processing method as the original data to obtain a plurality of positions in the corresponding bloom filter, and whether the 0 bit returned by the data recorder is one of the positions is judged; finally, carrying out non-carry addition by using the bit number in the stevenone filter corresponding to the 0 bit and the bit number in the random binary matrix, judging whether the obtained result is 0, if 0, and the previous verification is passed, believing that the query result is the query result, and if not 0, or if any previous verification fails, not believing the reply;
When the user receives the reply of 'present', firstly querying the blockchain to confirm the integrity of two merck tree roots in the presence certificate; secondly, respectively verifying the integrity of each row in the hidden bloom filter and each column in the random binary matrix by combining the mercer paths contained in the two mercer tree roots; then, the queried data is processed by the same processing method as the original data to obtain a plurality of positions in the corresponding bloom filter, and whether the generated characteristic field corresponds to the plurality of positions is judged; and finally, carrying out carry-free addition by using the digits in the corresponding stegand bloom filters and the digits in the random binary matrix, judging the obtained result, if the carry-free addition results are all 1 and the previous verification is passed, believing the reply, and if any carry-free addition result is not 1 or the previous verification is not passed, not believing the reply.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111302206.6A CN114238430B (en) | 2021-11-04 | 2021-11-04 | True storage method and system based on verifiable steganone filter |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111302206.6A CN114238430B (en) | 2021-11-04 | 2021-11-04 | True storage method and system based on verifiable steganone filter |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114238430A CN114238430A (en) | 2022-03-25 |
| CN114238430B true CN114238430B (en) | 2024-04-26 |
Family
ID=80748459
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111302206.6A Active CN114238430B (en) | 2021-11-04 | 2021-11-04 | True storage method and system based on verifiable steganone filter |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114238430B (en) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110024422A (en) * | 2016-12-30 | 2019-07-16 | 英特尔公司 | The name of Internet of Things and block chained record |
| CN112632187A (en) * | 2020-01-17 | 2021-04-09 | 天津灵创智恒软件技术有限公司 | Attribute hiding and canceling method based on counting bloom filter |
| CN112800055A (en) * | 2021-01-18 | 2021-05-14 | 湖北宸威玺链信息技术有限公司 | Data truth verification method, system, device and medium based on bloom filter |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20170017936A1 (en) * | 2015-07-14 | 2017-01-19 | Fmr Llc | Point-to-Point Transaction Guidance Apparatuses, Methods and Systems |
| CN112632567A (en) * | 2019-10-08 | 2021-04-09 | 杭州锘崴信息科技有限公司 | Multi-data-source full-flow encrypted big data analysis method and system |
-
2021
- 2021-11-04 CN CN202111302206.6A patent/CN114238430B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110024422A (en) * | 2016-12-30 | 2019-07-16 | 英特尔公司 | The name of Internet of Things and block chained record |
| CN112632187A (en) * | 2020-01-17 | 2021-04-09 | 天津灵创智恒软件技术有限公司 | Attribute hiding and canceling method based on counting bloom filter |
| CN112800055A (en) * | 2021-01-18 | 2021-05-14 | 湖北宸威玺链信息技术有限公司 | Data truth verification method, system, device and medium based on bloom filter |
Non-Patent Citations (3)
| Title |
|---|
| coded merkle tree:solving data availability attacks in blockchains;M Yu;international conference on financial cryptography and data security;20201231;全文 * |
| 基于区块链的网络安全体系结构与关键技术研究进展;徐恪;计算机学报;20210115;全文 * |
| 武继刚 ; 刘同来 ; 李境一 ; 黄金瑶 ; .移动边缘计算中的区块链技术研究进展.计算机工程.(08),全文. * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114238430A (en) | 2022-03-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20160191243A1 (en) | Out-of-band validation of domain name system records | |
| JP5215476B2 (en) | System and method for data authorization in a distributed storage network | |
| CN110011981B (en) | Trusted cloud storage method and system based on block chain | |
| US6097811A (en) | Tree-based certificate revocation system | |
| US7290133B1 (en) | Method and apparatus improving efficiency of end-user certificate validation | |
| CN110647503A (en) | Distributed storage method and device | |
| US8843751B2 (en) | IP address delegation | |
| CN110704864B (en) | Block chain-based government integrity archive license management method | |
| CN110309197B (en) | Project data verification method and device | |
| CN114301602B (en) | Video protection method and device based on block chain | |
| Khan et al. | Accountable and Transparent TLS Certificate Management: An Alternate Public‐Key Infrastructure with Verifiable Trusted Parties | |
| CN111694502B (en) | Block chain data storage method, device, equipment and storage medium | |
| CN109819068A (en) | User terminal and its block chain domain name analytic method | |
| CN109951482A (en) | User terminal and its block chain domain name analytic method | |
| CN112988667A (en) | Data storage method and device based on block chain network | |
| CN111353177A (en) | Block chain-based privacy large file storage system | |
| CN111177272A (en) | Block chain-based big data credible auditing method | |
| CN114238430B (en) | True storage method and system based on verifiable steganone filter | |
| CN109951481A (en) | Information processing method and system based on block chain network adjacent node | |
| CN111818029B (en) | Domain name request processing method and device | |
| US6941477B2 (en) | Trusted content server | |
| CN110808841B (en) | Communication system based on block chain network and communication method thereof | |
| CN114389878B (en) | Block chain slicing method and block chain network system | |
| CN114866260A (en) | Chameleon hash distributed identity use method and system | |
| CN115098893A (en) | Data storage method and device based on block chain |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20221108 Address after: 102308 Shilong Hi Tech Sunshine Building, 20 Yong'an Road, Mentougou District, Beijing Applicant after: Qingkehui (Beijing) Information Technology Co.,Ltd. Address before: 100084 Tsinghua Yuan, Beijing, Haidian District Applicant before: TSINGHUA University |
|
| TA01 | Transfer of patent application right | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |