CN114238430A - Real storage method and system based on verifiable covert bloom filter - Google Patents
Real storage method and system based on verifiable covert bloom filter Download PDFInfo
- Publication number
- CN114238430A CN114238430A CN202111302206.6A CN202111302206A CN114238430A CN 114238430 A CN114238430 A CN 114238430A CN 202111302206 A CN202111302206 A CN 202111302206A CN 114238430 A CN114238430 A CN 114238430A
- Authority
- CN
- China
- Prior art keywords
- bloom filter
- data
- binary matrix
- random binary
- rows
- 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.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 85
- 239000011159 matrix material Substances 0.000 claims abstract description 104
- 238000012795 verification Methods 0.000 claims abstract description 58
- 230000008569 process Effects 0.000 claims description 23
- 238000003672 processing method Methods 0.000 claims description 5
- 238000010276 construction Methods 0.000 claims description 3
- 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
- 238000006424 Flood reaction Methods 0.000 description 2
- 238000013507 mapping Methods 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 235000019796 monopotassium phosphate Nutrition 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 230000004075 alteration Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000004364 calculation method Methods 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
- 238000003780 insertion Methods 0.000 description 1
- 230000037431 insertion Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Images
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 Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Health & Medical Sciences (AREA)
- Computer Security & Cryptography (AREA)
- General Health & Medical Sciences (AREA)
- Bioethics (AREA)
- Computer Hardware Design (AREA)
- Data Mining & Analysis (AREA)
- Mathematical Physics (AREA)
- Computing Systems (AREA)
- Fuzzy Systems (AREA)
- Medical Informatics (AREA)
- Probability & Statistics with Applications (AREA)
- Computational Linguistics (AREA)
- Storage Device Security (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The application provides a real storage method based on a verifiable covert bloom filter, which comprises the following steps: recording the raw data to an empty bloom filter; when the original data reaches a preset capacity, constructing a random binary matrix with the same scale and carrying out non-carry addition on the random binary matrix to obtain a stego-bloom filter; constructing a Merck tree by the aid of the hidden bloom filter and the random binary matrix according to rows and columns, and recording two tree roots and a hash mode of recorded data into a block chain for storing certificates; receiving a verification request of a user, locally inquiring an acquisition result, acquiring corresponding rows and columns from a cryptic bloom filter and a random binary matrix, and constructing a Mercker certificate to be sent 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 corresponding bits of the bloom filter, and judging whether the data is recorded in the bloom filter. According to the method and the device, disclosed privacy data are obviously reduced under the condition of increasing a small amount of storage overhead.
Description
Technical Field
The application relates to the technical field of verifiable storage, in particular to a real storage method and a real storage system based on a verifiable covert bloom filter.
Background
True storage techniques based on blockchains:
the real storage is realized by taking the blockchain as a real storage platform, so that the data stored by a user can be ensured to be really stored and not be maliciously tampered, and a real response can be made in the face of a data access request of the user. In a real storage platform constructed based on a block chain, a user requests operations such as data addition, modification and revocation in a transaction form, and other users can read the contents of a database as required and complete subsequent calculation work based on the data. Throughout the flow of data access, the auditability provided by the blockchain data layer ensures that a user can verify the integrity of the data as it is accessed; the decentralized characteristic provided by the block chain network layer can effectively avoid the problem of single point failure; the consistency and non-tamper-ability provided by the blockchain consensus layer then ensures authenticity of the user's access to the acquired data. Compared with the traditional centralized storage platform, the distributed real storage constructed based on the block chain can stably operate, and the problems that a central server is down, maliciously tampered, data is concealed, or inconsistent access results are provided for different users and the like are effectively avoided.
The real storage technology based on the block chain is mainly used in the fields of evidence storage, collaborative databases and the like at the present stage and used for ensuring the integrity of data, when a user asks for the integrity of the data, a verifier can provide the evidence under the chain, and the user can carry out integrity verification by combining the evidence stored on the chain. The key technology for realizing true storage is to construct an Authenticatable Data Structure (ADS) designed for stored Data, such as a relatively common mercker tree in a block chain, under the ADS Structure, a mercker root is stored on the block chain to ensure integrity, when a leaf node (i.e., single Data) is verified, it is proved that a hash value on a corresponding mercker path and the mercker root need to be sent to a verifier, and the verifier queries the block chain to confirm the integrity of the mercker root first and then verifies the integrity of the Data corresponding to the leaf node by combining the mercker path. In recent years, with the widespread application of the blockchain technology, part of research has begun to explore new data structures to improve the blockchain query efficiency or enrich the query structure, and in order to ensure the verifiability of the data, the corresponding ADS structure needs to be designed specifically for the new data structures.
A bloom filter:
bloom Filters (BF) were proposed by Bloom in 1970. It is effectively a long binary vector and a series of random mapping functions. A bloom filter may be used to retrieve whether an element is in a collection. Its advantages are high space efficiency and inquiry time, high error recognition rate and high deletion difficulty.
The bloom filter is a bit array with the length of m and is used for recording data and inquiring whether certain data exists or not. 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 field modulo BF is used for remainder), and when the data is inserted, only the BF bit corresponding to the k fields needs to be set to 1; when the existence of certain data needs to be inquired, the k fields are calculated by hashing in the same method, whether the corresponding k positions in BF are simultaneously 1 or not is inquired, and if yes, the existence of the data with the maximum probability is shown; if any bit is 0, then the data must not exist. BF has a certain error rate, but the error rate can be reduced to be extremely low by adjusting the length of the bloom filter and the number of the hash fields.
When a BF recording n pieces of data is constructed, the optimal selection of the size m and the number k of hash functions can be obtained by the following equation:
k＝ln(2)×(n/m)
the bloom filter error rates corresponding to different values of k and n/m can be queried in fig. 3, where the second column in fig. 3 is an optimal design value of k, and since k must be an integer in the practical application process, k usually takes the largest integer value smaller than the optimal value.
The bloom filter can significantly reduce storage overhead and achieve query efficiency for O (1) complexity. Taking recording 1G pieces of data as an example: if 6 hash functions are selected and the error rate is ensured not to exceed 1%, the size of the bloom filter is 10G bit, namely 1.25 GB; if the hash value of each data is recorded without using a bloom filter, i.e., 32B, then the storage overhead is 32GB and the query overhead is at least o (logn).
The bloom filter can be verified:
the bloom filter is widely used for recording whether data exists, for example, in a Hash-Based IP trace technique (HBT), an intermediate node records a Hash value of a passed data packet, traces back the packet when a destination domain needs to query a packet forwarding path, sends a request to the intermediate node, and restores a real forwarding path of the data packet according to a response. To reduce storage overhead, it is a good strategy to use bloom filters to record packets
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 the variable fields (e.g., TTL, checksum, etc.) of the packet header, and takes the invariant fields (e.g., address field, flag field, etc.) of the packet header and the first eight bytes of the data packet portion as the 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 these are mapped to bloom filter position 1.
(3) When the destination end finds the malicious message, the source 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, the victim node V floods the inquiry request to the neighbor router, when the node does not store the message, the node ignores the request, when the node stores the message, the node continuously floods the request to the neighbor, and finally, a real forwarding path of the message is constructed and the node is traced back to the attack node.
However, in the above scheme, the integrity of the bloom filter locally at the intermediate node cannot be ensured, that is, the bloom filter queried by the node is actually generated by the recording packet at that time, and has not been tampered. Therefore, it is very necessary for the intermediate node to chain the hash of the bloom filter after locally recording data at certain time intervals. In such a form, however, the verifier would need to receive the entire bloom filter in order to verify its integrity, not only incurring a significant amount of communication overhead, but also revealing the privacy of other data packets recorded therein.
In order to solve the problems of too much communication overhead, too much leaked privacy data and the like in the verification process, a simple method is to construct a Mercker tree by segmenting a bloom filter, so that only a segment corresponding to a bit mapped by a data characteristic value needs to be returned in each verification, and the leaked privacy is obviously reduced. However, if the privacy protection is to be enhanced, the size of each segment needs to be reduced as much as possible, but the overhead caused by constructing the tacle tree is significantly increased, and in an extreme case, if the size of each segment is 1 bit, the storage overhead caused by constructing the tacle tree is 512 times that of the bloom filter; if the size of each segment is increased, the private data revealed by a single verification is also increased significantly.
Disclosure of Invention
The present application is directed to solving, at least to some extent, one of the technical problems in the related art.
Therefore, a first objective of the present application is to provide a real storage method based on a verifiable covert bloom filter, which solves the technical problems of too much communication overhead and privacy data leakage in the verification process of the verifiable storage method of the existing bloom filter, realizes the balance between the storage overhead and privacy protection while constructing the verifiable bloom filter, and significantly reduces the leaked privacy data under the condition of increasing a small amount of storage overhead, thereby effectively supporting the application of the verifiable bloom filter technology in the actual collaboration process.
In the application, a binary matrix is used for constructing a Bloom Filter, and for the Bloom Filter (BF) with the recorded data volume reaching the expected volume, a Random Binary Matrix (RBM) is firstly used for carrying out carry-free addition with the BF in the certificate storage process so as to obtain a Hidden Bloom Filter (HBF); then will concealThe bloom filter and the random two-mechanism matrix respectively construct a Merck tree according to rows and columns and carry out chain storage on the root hash. Based on the method, when responding to each data query and verification request, only the maximum k rows in the cryptic bloom filter and the maximum k columns in the random binary matrix need to be sent to the user terminal, and the user terminal can only obtain the maximum min { k } k in the bloom filter based on the received data2Kl bit, so that the amount of data leaked from a single verification is reduced from kl to min k2Kl where l is the number of bits contained in each row in the bloom filter, the number of bits leaked is significantly reduced. When the bloom filter size is larger than 128KB, the present application can reduce data leakage by at least 99% without increasing the storage overhead by more than a factor of two. In addition, the sizes of the rows and columns of the bloom filter can be adjusted according to the service scene, and the balance between privacy protection and the memory overhead of the Merckel tree is realized.
A second object of the present application is to propose a real storage system based on verifiable cryptic bloom filters.
In order to achieve the above object, an embodiment of a first aspect of the present application provides an authentic storage method based on a verifiable covert bloom filter, including: creating an empty bloom filter binary matrix, and recording original data into a 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 non-carry addition on the random binary matrix, thereby obtaining a cryptic bloom filter; constructing a Merck tree by a hidden bloom filter and a random binary matrix according to rows and columns respectively, and recording two tree roots and a Hash mode when the data is recorded by using the bloom filter into a block chain for storing certificates; receiving a verification request of a user, firstly locally inquiring an acquisition result, then acquiring corresponding rows and columns from a stego-bloom filter and a random binary matrix, and constructing a Merck certificate to be sent to a user terminal; and receiving the Mercker certification at the user side, verifying the integrity of rows in the hidden bloom filter and columns in the random binary matrix according to the received certification and a Mercker root stored in the block chain, recovering 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 a constructed bloom filter, first, according to a using method of a conventional bloom filter, a size of the bloom filter is determined according to a data amount and an accuracy requirement, and then, a number of rows and a number of columns of the bloom filter are set, where specific values of the number of rows and the number of columns are set according to an actual privacy protection requirement, and a number of positions to which record data in the bloom filter is mapped needs to be set to 1 for each record of one piece of data.
Optionally, in an embodiment of the present application, in the process of recording data in a bloom filter, the data to be recorded is hashed to obtain a plurality of feature fields, 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 an embodiment of the present application, the random binary matrix and the bloom filter have the same size, and after the random binary matrix and the bloom filter are not added together, the obtained covert bloom filter also has the same size, where the same size means that the number of rows, the number of columns, and the size are the same.
Optionally, in one embodiment of the present application, the stego-bloom filter constructs the merkel tree in rows, each row serving as a leaf node of the merkel tree; the random binary matrix constructs a Merck tree according to columns, each column is used as a leaf node of the Merck tree, two Merck tree roots and a hash mode corresponding to a bloom filter are placed on a block chain after the construction is finished, and the bloom filter, the random binary matrix and the stego bloom filter are stored locally.
Optionally, in an embodiment of the present application, for data requested to be queried and verified by a user, hash the data to obtain a plurality of feature fields, and map the feature fields to a plurality of locations in a bloom filter, if there is one of the feature fields mapped to a location of 0, determine that the data is not recorded in the bloom filter, then return the result, and construct an absence certificate; if the positions mapped by all the characteristic fields are 1, determining that the data is recorded in the bloom filter, returning the result, and constructing the existence certification, wherein the data requesting the query and the verification is in the same hash mode as the original data.
Optionally, in an embodiment of the present application, when the user receives a "non-existent" reply, the blockchain is queried first to confirm the integrity of the two mercker roots in the non-existent proof; secondly, verifying the integrity of rows in the hidden bloom filter and columns in the random binary matrix by combining a Merckel path; then, the inquired 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 position 0 returned by the data recorder is one of the positions is judged; and finally, carrying out carry-free addition by using the digit in the stego bloom filter corresponding to the position 0 and the digit in the random binary matrix, and judging whether the obtained result is 0: if the number is 0 and the previous verification is passed, the query result is believed; if not 0, or if any of the previous verifications fail, the reply is not trusted.
Optionally, in an embodiment of the present application, when the user receives the reply "exist", the blockchain is queried first to confirm the integrity of the two mercker roots in the existence certification; secondly, verifying the integrity of each row in the cryptic bloom filter and each column in the random binary matrix respectively by combining the Mercker paths contained in the two Mercker roots; then, the inquired 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; finally, sequentially carrying out non-carry addition by using the digits in the stego-bloom filter corresponding to a plurality of positions and the digits in the random binary matrix, and judging the obtained result: if the result of the not-carry addition is 1 and the previous verification is passed, the reply is believed to be carried out; if any one of the carry-out addition results is not 1 or any previous verification fails, the reply is not believed.
To achieve the above object, an embodiment of a second aspect of the present application provides an authentic storage system based on a verifiable cryptic bloom filter, including: a data recording side and a verifying side, 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 non-carry addition on the random binary matrix, thereby obtaining a cryptic bloom filter; constructing a Merck tree by a hidden bloom filter and a random binary matrix according to rows and columns respectively, and recording two tree roots and a Hash mode when the data is recorded by using the bloom filter into a block chain for storing certificates;
the data recording party is also used for receiving a verification request sent by the verification party, locally inquiring an acquisition result, acquiring corresponding rows and columns from the cryptic bloom filter and the random binary matrix, constructing a Merck certificate and sending the Merck certificate to the verification party;
and the verifying party is also used for receiving the Mercker certificate, verifying the integrity of rows in the hidden bloom filter and columns in the random binary matrix according to the received certificate and a Mercker root stored in the block chain, recovering 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 covert bloom filter solve the technical problems that communication overhead and leaked private data are too much in the verification process of the verifiable storage method of the conventional bloom filter, realize balance between storage overhead and privacy protection while constructing the verifiable bloom filter, obviously reduce the leaked private data under the condition of increasing a small amount of storage overhead, and effectively support the application of the verifiable bloom filter technology in the actual cooperation process.
In the application, a binary matrix is used for constructing a Bloom Filter, and for the Bloom Filter (BF) with the recorded data volume reaching the expected volume, a Random Binary Matrix (RBM) is firstly used for carrying out carry-free addition with the BF in the certificate storage process so as to obtain a Hidden Bloom Filter (HBF); then apply the cryptic bloom filter and randomizerThe two mechanism matrixes construct a Merck tree according to rows and columns respectively and carry out chain loading and evidence storing on the root hash of the tree. Based on the method, when responding to each data query and verification request, only the maximum k rows in the cryptic bloom filter and the maximum k columns in the random binary matrix need to be sent to the user terminal, and the user terminal can only obtain the maximum min { k } k in the bloom filter based on the received data2Kl bit, so that the amount of data leaked from a single verification is reduced from kl to min k2Kl where l is the number of bits contained in each row in the bloom filter, the number of bits leaked is significantly reduced. When the bloom filter size is larger than 128KB, the present application can reduce data leakage by at least 99% without increasing the storage overhead by more than a factor of two. In addition, the sizes of the rows and columns of the bloom filter can be adjusted according to the service scene, and the balance between privacy protection and the memory overhead of the Merckel tree is realized.
Additional aspects and advantages of the present 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 present application.
Drawings
The foregoing and/or additional aspects and advantages of the present application will become apparent and readily appreciated from the following description of the embodiments, taken in conjunction with the accompanying drawings of which:
fig. 1 is a flowchart of a real storage method based on a verifiable covert bloom filter according to an embodiment of the present application;
FIG. 2 is a schematic diagram of data insertion and query operations of a bloom filter according to 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 method for true storage based on a verifiable cryptic bloom filter in accordance with an embodiment of the present application;
FIG. 5 is a schematic diagram of a bloom filter based on a verifiable covert bloom filter-based true storage method according to an embodiment of the present application;
fig. 6 is a schematic flow chart of a method for obtaining a data feature value based on a verifiable covert bloom filter-based true storage method according to an embodiment of the present application;
fig. 7 is a schematic diagram of computing a cryptic bloom filter based on a verifiable cryptic bloom filter-based true storage method according to an embodiment of the present application;
FIG. 8 is a block diagram of a Merck tree based on a verifiable cryptic bloom filter-based true storage method according to an embodiment of the present application;
FIG. 9 is a schematic flowchart of a method for restoring an original Merck tree based on a verifiable covert bloom filter-based real storage method according to an embodiment of the present application;
fig. 10 is a schematic structural diagram of an authentic storage system based on a verifiable covert bloom filter according to a second embodiment of the present application.
Detailed Description
Reference will now be made in detail to embodiments of the present application, examples of which are illustrated in the accompanying drawings, wherein like or similar reference numerals refer to the same or similar elements or elements having the same or similar function throughout. The embodiments described below with reference to the drawings are exemplary and intended to be used for explaining the present application and should not be construed as limiting the present application.
The following describes a truthful storage method and system based on a verifiable cryptic bloom filter according to an embodiment of the present application with reference to the drawings.
Fig. 1 is a flowchart of an authentic storage method based on a verifiable cryptic bloom filter according to an embodiment of the present application.
As shown in fig. 1, the authentic storage method based on verifiable cryptic bloom filter includes the following steps:
103, constructing a Merck tree by the hidden bloom filter and the random binary matrix according to rows and columns respectively, and recording two tree roots and a hash mode when the data is recorded by the bloom filter into a block chain for storage;
104, receiving a verification request of a user, locally inquiring an acquisition result, acquiring corresponding rows and columns from a cryptic bloom filter and a random binary matrix, constructing a Mercker certificate and sending the Mercker certificate to a user side;
and 105, receiving the Mercker certification at the user side, verifying the integrity of rows in the hidden bloom filter and columns in the random binary matrix according to the received certification and the Mercker root stored in the block chain, recovering corresponding bits of the bloom filter, and finally judging whether the data is recorded in the bloom filter.
According to the true storage method based on the verifiable covert bloom filter, an empty binary matrix of the bloom filter is created, and original data are recorded 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 non-carry addition on the random binary matrix, thereby obtaining a cryptic bloom filter; constructing a Merck tree by a hidden bloom filter and a random binary matrix according to rows and columns respectively, and recording two tree roots and a Hash mode when the data is recorded by using the bloom filter into a block chain for storing certificates; receiving a verification request of a user, firstly locally inquiring an acquisition result, then acquiring corresponding rows and columns from a stego-bloom filter and a random binary matrix, and constructing a Merck certificate to be sent to a user terminal; and receiving the Mercker certification at the user side, verifying the integrity of rows in the hidden bloom filter and columns in the random binary matrix according to the received certification and a Mercker root stored in the block chain, recovering corresponding bits of the bloom filter, and finally judging whether the data is recorded in the bloom filter. Therefore, the technical problems that communication overhead and leaked privacy data are excessive in the verification process of the verifiable storage method of the existing bloom filter can be solved, the storage overhead and privacy protection are balanced while the verifiable bloom filter is constructed, the leaked privacy data are obviously reduced under the condition that a small amount of storage overhead is increased, and the application of the verifiable bloom filter technology in the actual cooperation process is effectively supported.
In the application, a binary matrix is used for constructing a Bloom Filter, and for the Bloom Filter (BF) with the recorded data volume reaching the expected volume, a Random Binary Matrix (RBM) is firstly used for carrying out carry-free addition with the BF in the certificate storage process so as to obtain a Hidden Bloom Filter (HBF); and then constructing a Merck tree by the hidden bloom filter and the random two-mechanism matrix according to rows and columns respectively, and carrying out chain storage on the root hash. Based on the method, when responding to each data query and verification request, only the maximum k rows in the cryptic bloom filter and the maximum k columns in the random binary matrix need to be sent to the user terminal, and the user terminal can only obtain the maximum min { k } k in the bloom filter based on the received data2Kl bit, so that the amount of data leaked from a single verification is reduced from kl to min k2Kl where l is the number of bits contained in each row in the bloom filter, the number of bits leaked is significantly reduced. When the bloom filter size is larger than 128KB, the present application can reduce data leakage by at least 99% without increasing the storage overhead by more than a factor of two. In addition, the sizes of the rows and columns of the bloom filter can be adjusted according to the service scene, and the balance between privacy protection and the memory overhead of the Merckel tree is realized.
According to the method, each bloom filter generates a matched random number, and when the characteristic field of the recorded data is generated, the data and the random number need to be combined and then hashed. Each random number is not externally disclosed in the use process of the corresponding bloom filter, and when the bloom filter finishes recording (namely, records the preset data amount) and links the data, the matched random number is linked to be disclosed, so that specific manufacturing data of an attacker is avoided, and certain specified unrecorded data is mistakenly considered to be recorded in the bloom filter. In addition, in order to reduce the hash times, when the characteristic field is generated, data is hashed only once, and then the data is divided into k segments, 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 plurality of hash values are divided into k segments.
Further, in this embodiment of the application, for a constructed bloom filter, first, according to a using method of a conventional bloom filter, the size of the bloom filter is determined according to the data size and accuracy requirement, and then the number of rows and columns of the bloom filter are set, specific values of the number of rows and columns are set according to actual privacy protection requirements, and each record of one piece of data requires that a plurality of positions to which record data in the bloom filter is mapped are set to be 1.
For a constructed bloom filter, the number of rows is s, the number of columns is l, the total size is m ═ sl, k bits in the bloom filter need to be set to 1 for each piece of data to be recorded, and the upper limit of the data capacity that the bloom filter can record is n, then m and k can be selected according to different error rate expectations and requirements for n, with reference to fig. 3.
Further, in the embodiment of the present application, in the process of recording data in the bloom filter, the data to be recorded is hashed to obtain a plurality of feature fields, each feature field is then 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 into the bloom filter, hashing the data to be recorded to obtain a k characteristic field, CiRepresenting the ith characteristic field (the hash mode corresponding to each bloom filter is different, and the specific hash mode is disclosed in the process of storing the certificate of the bloom filter), and then, displaying each characteristic field CiMapping to a position BF x in a bloom Filter BFi][yi]Corresponding row xiIs (c)i/' l)% s, corresponding column yiIs then ci% l, finally set this k bit in the bloom filter to 1.
Further, in the embodiment of the present application, the random binary matrix and the bloom filter have the same scale, and after the non-carry addition is performed on the random binary matrix and the bloom filter, the obtained cryptic bloom filter also has the same scale, where the same scale refers to the same number of rows, the same number of columns, and the same size.
The random binary matrix is the same size as the bloom filter, with s number of rows, l number of columns, and a total size of m to sl. After the random binary matrix and the bloom filter are added without carry, the obtained cryptic bloom filter has the same scale, that is, 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 present application, the stego-bloom filter constructs the merkel tree in rows, where each row is used as a leaf node of the merkel tree and has a length of l; the random binary matrix constructs a Merck tree according to columns, each column is used as a leaf node of the Merck tree, the length is s, after the construction is finished, two Merck tree roots and a hash mode corresponding to a bloom filter are placed on a block chain (the block chain can be any existing public chain or a union chain), and the bloom filter, the random binary matrix and the stego bloom filter are stored locally.
Further, in the embodiment of the present application, for data requested to be queried and verified by a user, the data is hashed to obtain a plurality of feature fields, and the feature fields are mapped to a plurality of positions in a bloom filter, and if there is one feature field mapped to a position of 0, it is determined that the data is not recorded in the bloom filter, and then the result is returned, and an absence certificate is constructed; if the positions mapped by all the characteristic fields are 1, determining that the data is recorded in the bloom filter, returning the result, and constructing the existence certification, wherein the data requesting the query and the verification is in the same hash mode as the original data.
For Data requested to be inquired and verified by a user, a Data logger hashes the Data by creating an empty bloom filter binary matrix to record the Data into a bloom filter to obtain k characteristic fields, and maps the k characteristic fields to k positions in the bloom filter, wherein if one characteristic field c existsvMapped position BF [ x ]v][yv]A value of 0 indicates that the data is not recorded in the bloom filter, and the result is returned and the absence of proof P is constructedNLattice of itThe formula is as follows:
PN：＝{HBF[xv][：]，RBM[：][yv]，MKP1，MKP2，MKR1，MKR2}
wherein, HBF [ x ]v][：]Is the x-th of the cryptic bloom Filter HBFvRow, RBM [:][yv]is the y-th of the random binary matrix RBMvColumn, MKP1And MKP2Are respectively used for verifying HBF [ x ]v][：]And RBM [:][yv]merkel path of MKR1And MKR2Is the corresponding mercker root.
If all the characteristic fields are mapped to the position BF [ x ] for the Datai][yi]All 1, then the data is recorded in the bloom filter, the result is returned, and a presence credential P is constructedYThe format is as follows:
PY：＝{HBF[x1：xk][：]，RBM[：][y1：yk]，MKP1，MKP2，MKR1，MKR2}
wherein, HBF [ x ]1：xk][：]Is k rows in the stego bloom filter HBF, RBM [:][y1：yk]is k columns, x of a random binary matrix RBMiAnd yiAs a characteristic value c of the DATA DATAiThe row and column numbers, MKPs, corresponding to the mapped bloom filter locations1And MKP2Respectively containing verification HBF [ x1：xk][：]And RBM [:][y1：yk]merkel path of MKR1And MKR2Is the corresponding mercker root.
Further, in the embodiment of the present application, when the user receives the "nonexistence" reply, the blockchain is queried first to confirm the nonexistence proof PNMiddle two mercker roots MKR1And MKR2The integrity of (a); second, Merkel path MKP is combined1And MKP2Verification of line HBF x in hidden bloom Filterv][：]And column RBM in random binary matrix [:][yv]the integrity of (a); then, willThe inquired data is processed by the same method as the original data to obtain k positions in the corresponding bloom filter, and (x) is judgedv，yv) Whether it is one of them; finally, with HBF [ x ]v][：]Middle (y)vBit and RBM [:][yv]middle (x)vAdding the bits without carry, and judging the obtained result: if the number is 0 and the previous verification is passed, the query result is believed; if not 0, or if any of the previous verifications fail, the reply is not trusted.
Further, in the embodiment of the present application, when the user receives the reply "presence", the blockchain is queried first to confirm the presence certificate PYMiddle two mercker roots MKR1And MKR2The integrity of (a); secondly, verifying the integrity of each row in the cryptic bloom filter and each column in the random binary matrix respectively by combining the Mercker paths contained in the two Mercker roots; then, the inquired data is processed by the same processing method as the original data to obtain k positions in the corresponding bloom filter, and the generated characteristic field (x) is judged1，y1)，(x2，y2)，…，(xk，yk) Whether or not to correspond to the k positions; finally, HBF [ x ] is used successivelyi][：]Y in (1)iBit and RBM [:][yi]x of (1)iAdding the bits without carry to obtain k bits, and judging the obtained result: if the k bits are all 1 and the previous verification passes, the reply is deemed to be; if there is any bit that is 0, or if any previous verification fails, then the reply is not trusted.
Fig. 4 is another flowchart of an authentic storage method based on a verifiable cryptic bloom filter according to an embodiment of the present application.
As shown in fig. 4, in the authentic storage method based on verifiable covert bloom filter, the data logger creates an empty bloom filter binary matrix and logs the data into the bloom filter; when the data recorded by the bloom filter reaches a preset capacity, a data recorder constructs a random binary matrix with the same scale and carries out non-carry addition with the random binary matrix, so that a secret bloom filter is obtained; the data recording party constructs a Merck tree by a hidden bloom filter according to rows, constructs a Merck tree by a random binary matrix according to columns, and records two tree roots and a Hash mode when the data is recorded by the bloom filter into a block chain for storing the certificate; aiming at the verification request of a user, a data recording party firstly queries an acquisition result locally, then acquires corresponding rows and columns from a cryptic bloom filter and a random binary matrix, constructs a Merck certificate and sends the Merck certificate to the user; the user firstly verifies the integrity of rows in the hidden bloom filter and columns in the random binary matrix according to the received certification and the Mercker root stored in the block chain, 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 real storage method according to an embodiment of the present application.
As shown in fig. 5, the bloom filter based on the authentic storage method of the verifiable covert bloom filter has the row number of s, the column number of l, and the total size of m ═ sl bit.
Fig. 6 is a schematic flowchart of a method for obtaining a data feature value based on a verifiable cryptic bloom filter-based true storage according to an embodiment of the present application.
As shown in fig. 6, in the true storage method based on verifiable covert bloom filter, for a data, combining it with a random number r and hashing it to obtain a 32-byte hash value, considering that the feature value will map to one bit in the bloom filter, the length of the feature value must be greater than or equal to log2And m, therefore, the length of the characteristic value can be determined according to the actual service requirement, and if one hash value is not enough to meet the length requirement of the k characteristic values, a plurality of random numbers can be generated for each bloom filter and are respectively combined with data to generate a plurality of hash values. The characteristic field considered in fig. 5 is 8 bytes in length, i.e. 64 bits, sufficient for the size not to exceed 264All bloom filter requirements for bit, where a hash value can be divided into 4 eigenvalues.
Fig. 7 is a schematic diagram of computing a cryptic bloom filter based on a verifiable cryptic bloom filter real storage method according to an embodiment of the present application.
As shown in fig. 7, in the true storage method based on the verifiable covert bloom filter, the data logger first constructs a random binary matrix with the same size as the bloom filter, where the number of rows is s, the number of columns is l, and the total size is m ═ sl. After the non-carry addition of the bloom filter rule and the random binary matrix, the obtained cryptic bloom filter 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 merkel tree diagram of a real storage method based on a verifiable cryptic bloom filter according to an embodiment of the present application.
As shown in fig. 8, the merkel tree based on the true storage method of verifiable crypt bloom filter is constructed by a crypt bloom filter with a row number of 8, and the hash value of each row is combined with the corresponding row number to be used as a leaf node of the merkel tree, that is: hash is i H (HBF i:), the middle node is the hash of the left and right child nodes after the corresponding hash values are combined, finally a Mercker root can be obtained. When the corresponding number of rows and the merkel proof are returned to the user, assuming that the row 1 is returned, the corresponding merkel path is:
{1，Hash0，H(Hash2||Hash3)，H(H(Hash4||Hash5)||H(Hash6||Hash7))，MKR}
after receiving the merkel path and the first row of cryptic bloom filters, the user firstly combines and hashes the row number 1 with the row of cryptic bloom filters to obtain Hash1, then combines the Hash1 with Hash0 to obtain H (Hash0| | | Hash1), and gradually combines and hashes to obtain a merkel root MKR', and judges whether the calculated merkel root is the same as MKR and MKR is in the previous recorded block chain, if the verification is passed, the integrity verification of the first row of cryptic bloom filters is completed.
Fig. 9 is a schematic flowchart of recovering an original merkel tree based on a verifiable cryptic bloom filter-based real storage method according to an embodiment of the present application.
As shown in fig. 9, it is assumed here that the number of eigenvalues k generated when each data is recorded in the bloom filter is 4, and the bits are mapped to the bits of the original bloom filterRespectively as follows: BF [ i ]1][j1]，BF[i2][j2]，BF[i3][j3]And BF [ i4][j4]. Therefore, the data logger returns to the verifier the corresponding 4-row stego bloom filter and 4-column random binary matrix as follows:
{(HBF[i1][：]，RBM[：][j1])，(HBF[i2][：]，RBM[：][j2])，
(HBF[i3][：]，RBM[：][j3])，(HBF[i4][：]，RBM[：][j4])}
the verifier verifies the integrity of the data based on the Mercker path and the chain verification record and determines a row and column number, the verification data is hashed with the random number stored in the chain to obtain 4 characteristic values, and the 4 characteristic values are mapped to 4 bits in the bloom filter, wherein the row and column numbers are (i'1，j′1)，(i′2，j′2)，(i′3，j′3) And (i'4，j′4) And after the verification passes through the comparison with the row and column numbers obtained in the previous verification process, recovering 4 bits corresponding to the original bloom filter. Using HBF [ i ] as an example to recover the first bit1][：]J (d) of1Bit and RBM [:][j1]i th of (1)1After recovering 4 bits, if all the bits are 1, judging that the high probability of the verified data is recorded in the bloom filter; if any bit is 0, then the verified data must not be in the bloom filter. White in the figure represents the successfully recovered bit, black represents the leaked privacy bit, and the total number of bits leaked by single verification can be judged not to exceed k2Wherein the privacy bit does not exceed k (k-1).
Fig. 10 is a schematic structural diagram of an authentic storage system based on a verifiable covert bloom filter according to a second embodiment of the present application.
As shown in fig. 10, the authentic storage system based on verifiable cryptic bloom filter includes: a data recording side and a verifying side, 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 non-carry addition on the random binary matrix, thereby obtaining a cryptic bloom filter; constructing a Merck tree by a hidden bloom filter and a random binary matrix according to rows and columns respectively, and recording two tree roots and a Hash mode when the data is recorded by using the bloom filter into a block chain for storing certificates;
the data recording party is also used for receiving a verification request sent by the verification party, locally inquiring an acquisition result, acquiring corresponding rows and columns from the cryptic bloom filter and the random binary matrix, constructing a Merck certificate and sending the Merck certificate to the verification party;
and the verifying party is also used for receiving the Mercker certificate, verifying the integrity of rows in the hidden bloom filter and columns in the random binary matrix according to the received certificate and a Mercker root stored in the block chain, recovering corresponding bits of the bloom filter, and finally judging whether the data is recorded in the bloom filter.
The real storage system based on the verifiable covert bloom filter comprises a data recording party and a verifying party, wherein the data recording party is used for creating an empty binary matrix of the bloom filter 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 non-carry addition on the random binary matrix, thereby obtaining a cryptic bloom filter; constructing a Merck tree by a hidden bloom filter and a random binary matrix according to rows and columns respectively, and recording two tree roots and a Hash mode when the data is recorded by using the bloom filter into a block chain for storing certificates; the data recording party is also used for receiving a verification request sent by the verification party, locally inquiring an acquisition result, acquiring corresponding rows and columns from the cryptic bloom filter and the random binary matrix, constructing a Merck certificate and sending the Merck certificate to the verification party; and the verifying party is also used for receiving the Mercker certificate, verifying the integrity of rows in the hidden bloom filter and columns in the random binary matrix according to the received certificate and a Mercker root stored in the block chain, recovering corresponding bits of the bloom filter, and finally judging whether the data is recorded in the bloom filter. Therefore, the technical problems that communication overhead and leaked privacy data are excessive in the verification process of the verifiable storage method of the existing bloom filter can be solved, the storage overhead and privacy protection are balanced while the verifiable bloom filter is constructed, the leaked privacy data are obviously reduced under the condition that a small amount of storage overhead is increased, and the application of the verifiable bloom filter technology in the actual cooperation process is effectively supported.
In the application, a binary matrix is used for constructing a Bloom Filter, and for the Bloom Filter (BF) with the recorded data volume reaching the expected volume, a Random Binary Matrix (RBM) is firstly used for carrying out carry-free addition with the BF in the certificate storage process so as to obtain a Hidden Bloom Filter (HBF); and then constructing a Merck tree by the hidden bloom filter and the random two-mechanism matrix according to rows and columns respectively, and carrying out chain storage on the root hash. Based on the method, when responding to each data query and verification request, only the maximum k rows in the cryptic bloom filter and the maximum k columns in the random binary matrix need to be sent to the user terminal, and the user terminal can only obtain the maximum min { k } k in the bloom filter based on the received data2Kl bit, so that the amount of data leaked from a single verification is reduced from kl to min k2Kl where l is the number of bits contained in each row in the bloom filter, the number of bits leaked is significantly reduced. When the bloom filter size is larger than 128KB, the present application can reduce data leakage by at least 99% without increasing the storage overhead by more than a factor of two. In addition, the sizes of the rows and columns of the bloom filter can be adjusted according to the service scene, and the balance between privacy protection and the memory overhead of the Merckel tree is realized.
In the description herein, reference to the description of the term "one embodiment," "some embodiments," "an example," "a specific example," 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 application. In this specification, the schematic representations of the terms used above are not necessarily intended to refer 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, various embodiments or examples and features of different embodiments or examples described in this specification can be combined and combined by one skilled in the art without contradiction.
Furthermore, the terms "first", "second" and "first" are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one such feature. In the description of the present application, "plurality" means at least two, e.g., two, three, etc., unless specifically limited 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 steps of a custom logic function or process, and alternate 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, depending on the functionality involved, as would be understood by those reasonably skilled in the art of the present application.
The logic and/or steps represented in the flowcharts or otherwise described herein, e.g., an ordered listing of executable instructions that can be considered to implement 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). Additionally, the computer-readable medium could even be paper or another suitable medium upon which the program is printed, as the program can 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 should be understood that portions of the present application may be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, the various steps or methods may be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. If implemented in hardware, as in another embodiment, any one or combination of the following techniques, which are known in the art, may be used: a discrete logic circuit having a logic gate circuit for implementing a logic function on a data signal, an application specific integrated circuit having an appropriate combinational logic gate circuit, a Programmable Gate Array (PGA), a Field Programmable Gate Array (FPGA), or the like.
It will be understood by those skilled in the art that all or part of the steps carried by the method for implementing the above embodiments may be implemented by hardware related to instructions of a program, which may be stored in a computer readable storage medium, and when the program is executed, the program includes one or a combination of the steps of the method embodiments.
In addition, functional units in the embodiments of the present application may be integrated into one processing module, or each unit may exist alone physically, or two or more units are integrated into one module. The integrated module can be realized in a hardware mode, and can also be realized in a software functional module mode. The integrated module, if implemented in the form of a software functional module and sold or used as a stand-alone product, may also be stored in a computer readable storage medium.
The storage medium mentioned above may be a read-only memory, a magnetic or optical disk, etc. Although embodiments of the present application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present application, and that variations, modifications, substitutions and alterations may be made to the above embodiments by those of ordinary skill in the art within the scope of the present application.
Claims (9)
1. A truthful storage method based on a verifiable cryptic bloom filter is characterized by comprising the following steps:
creating an empty bloom filter binary matrix, and recording original data into a 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 non-carry addition on the random binary matrix, thereby obtaining a cryptic bloom filter;
constructing a Merck tree by the hidden bloom filter and the random binary matrix according to rows and columns respectively, and recording two tree roots and a hash mode when the data is recorded by the bloom filter into a block chain for storing certificates;
receiving a verification request of a user, firstly locally inquiring an acquisition result, then acquiring corresponding rows and columns from a stego-bloom filter and a random binary matrix, and constructing a Merck certificate to be sent to a user terminal;
and receiving the Mercker certification at a user terminal, verifying the integrity of rows in the hidden bloom filter and columns in the random binary matrix according to the received certification and a Mercker root stored in the block chain, recovering corresponding bits of the bloom filter, and finally judging whether data is recorded in the bloom filter.
2. The method as claimed in claim 1, wherein for the constructed bloom filter, firstly, according to the using method of the traditional bloom filter, the size of the bloom filter is determined according to the data volume and accuracy requirement, and then the row number and column number of the bloom filter are set, the specific values of the row number and column number are set according to the actual privacy protection requirement, and each record of one piece of data needs to set the positions to which the record data in the bloom filter are mapped to as 1.
3. The method of claim 2, wherein in the process of recording data into the bloom filter, data to be recorded is hashed to obtain a plurality of characteristic fields, each characteristic field is mapped to a position in the bloom filter, the 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 wherein the random binary matrix and the bloom filter are not added together, and wherein the resulting cryptic bloom filter is the same size, wherein the same size means the same number of rows, columns, and size.
5. The method of claim 1, wherein the stego-bloom filter constructs the merkel tree in rows, each row being a leaf node of the merkel tree; the random binary matrix constructs a Merck tree according to columns, each column is used as a leaf node of the Merck tree, two Merck tree roots and a hash mode corresponding to a bloom filter are placed on a block chain after the construction is finished, and the bloom filter, the random binary matrix and the secret bloom filter are stored locally.
6. The method of claim 1, wherein for data requested by a user for query and verification, the data is hashed to obtain a number of characteristic fields and mapped to a number of locations in a bloom filter,
if the position mapped by one of the characteristic fields is 0, determining that the data is not recorded in the bloom filter, returning the result and constructing an absence certificate;
if all the feature fields map to positions of 1, then the data is determined to be recorded in the bloom filter, the result is returned, and a presence certificate is constructed,
and the hash mode of the data requested to be queried and verified is the same as that of the original data.
7. The method of claim 6, wherein when the user receives a "nonexistent" reply, the blockchain is queried first to confirm the integrity of the two mercker roots in the nonexistent; secondly, verifying the integrity of rows in the hidden bloom filter and columns in the random binary matrix by combining a Merckel path; then, the inquired 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 position 0 returned by the data recorder is one of the positions is judged; and finally, carrying out non-carry addition by using the digit in the stego bloom filter corresponding to the position 0 and the digit in the random binary matrix, and judging whether the obtained result is 0:
if the number is 0 and the previous verification is passed, the query result is believed;
if not 0, or if any of the previous verifications fail, the reply is not trusted.
8. The method of claim 6, wherein when the user receives the reply "Presence", the blockchain is queried to confirm the integrity of the two Mercker roots in the proof of Presence; secondly, verifying the integrity of each row in the cryptic bloom filter and each column in the random binary matrix respectively by combining the Mercker paths contained in the two Mercker roots; then, the inquired 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; finally, sequentially carrying out non-carry addition by using the digits in the stego-bloom filter corresponding to a plurality of positions and the digits in the random binary matrix, and judging the obtained result:
if the result of the not-carry addition is 1 and the previous verification is passed, the reply is believed to be carried out;
if any one of the carry-out addition results is not 1 or any previous verification fails, the reply is not believed.
9. A real storage system based on verifiable cryptic bloom filter is characterized by comprising a data recording party and a verifying party, wherein,
the data logger 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 non-carry addition on the random binary matrix, thereby obtaining a cryptic bloom filter; constructing a Merck tree by the hidden bloom filter and the random binary matrix according to rows and columns respectively, and recording two tree roots and a hash mode when the data is recorded by the bloom filter into a block chain for storing certificates;
the data recording party is also used for receiving a verification request sent by the verification party, locally inquiring an acquisition result, acquiring corresponding rows and columns from the cryptic bloom filter and the random binary matrix, constructing a Merck certificate and sending the Merck certificate to the verification party;
the verifying party is further configured to receive the tacle proof, verify integrity of rows in the hidden bloom filter and columns in the random binary matrix according to the received proof and the tacle root stored in the block chain, recover corresponding bits of the bloom filter, and finally judge whether data is recorded in the bloom filter.
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 true CN114238430A (en) | 2022-03-25 |
| CN114238430B 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 (5)
| 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 |
| 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 |
| US20210117395A1 (en) * | 2019-10-08 | 2021-04-22 | Hangzhou Nuowei Information Technology Co., Ltd. | Whole-lifecycle encrypted big data analysis method and system for the data from the different sources |
| CN112800055A (en) * | 2021-01-18 | 2021-05-14 | 湖北宸威玺链信息技术有限公司 | Data truth verification method, system, device and medium based on bloom filter |
-
2021
- 2021-11-04 CN CN202111302206.6A patent/CN114238430B/en active Active
Patent Citations (5)
| 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 |
| CN110024422A (en) * | 2016-12-30 | 2019-07-16 | 英特尔公司 | The name of Internet of Things and block chained record |
| US20210117395A1 (en) * | 2019-10-08 | 2021-04-22 | Hangzhou Nuowei Information Technology Co., Ltd. | Whole-lifecycle encrypted big data analysis method and system for the data from the different sources |
| 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 (2)
| Title |
|---|
| M YU: "coded merkle tree:solving data availability attacks in blockchains", INTERNATIONAL CONFERENCE ON FINANCIAL CRYPTOGRAPHY AND DATA SECURITY, 31 December 2020 (2020-12-31) * |
| 徐恪: "基于区块链的网络安全体系结构与关键技术研究进展", 计算机学报, 15 January 2021 (2021-01-15) * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114238430B (en) | 2024-04-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10230526B2 (en) | Out-of-band validation of domain name system records | |
| US6097811A (en) | Tree-based certificate revocation system | |
| US6134550A (en) | Method and apparatus for use in determining validity of a certificate in a communication system employing trusted paths | |
| CN110647503A (en) | Distributed storage method and device | |
| US9098725B2 (en) | Cryptographic accumulators for authenticated hash tables | |
| CN111159288A (en) | Method, system, device and medium for storing, verifying and realizing chain structure data | |
| US11475150B2 (en) | Methods and apparatus for implementing state proofs and ledger identifiers in a distributed database | |
| CN109376528B (en) | Trusted identity management system and method based on block chain | |
| CA2731954C (en) | Apparatus, methods, and computer program products providing dynamic provable data possession | |
| US8447971B2 (en) | Self-signed implicit certificates | |
| CN108897760A (en) | Electronic evidence chain integrity verification method based on Merkel tree | |
| CN110263584B (en) | Block chain-based data integrity auditing method and system | |
| CN106991148B (en) | Database verification system and method supporting full-update operation | |
| WO2022068356A1 (en) | Blockchain-based information encryption method and apparatus, device and medium | |
| CN112637330B (en) | Block chain large file copy address selection method, system, equipment and storage medium | |
| US20240080181A1 (en) | Blockchain Data Structures and Systems and Methods Therefor for Multipath Transaction Management | |
| CN115208628B (en) | Data integrity verification method based on block chain | |
| CN113411376A (en) | Sensor data processing method and device based on block chain fragmentation storage | |
| US20230108083A1 (en) | Transaction verification system and method of operation thereof | |
| CN114238430A (en) | Real storage method and system based on verifiable covert bloom filter | |
| CN114866260B (en) | Chameleon hash distributed identity using method and system | |
| CN112527808A (en) | Data integrity verification method supporting dynamic update in cloud storage service | |
| CN114422138B (en) | Certificate transparentization method and system for domain name owner user-defined verification strategy | |
| Aslam et al. | A Study to Distribute the Data of Blockchain in a DHT-Based System for DNS | |
| CN113672686B (en) | Block data distribution and storage method and system |
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 | ||
| 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 |
|
| GR01 | Patent grant | ||
| GR01 | Patent grant |