Never trust that the server delete data. - Sent from my tablet Den 21 jul 2012 11:15 skrev <[email protected]>:
> Hello, I have a question regarding encrypted bloom filter protocols. I > have come to the understanding that I can use such protocols to allow a > client to query a server for the presence of a string, "string". Due to the > properties of the encrypted bloom filter protocol, the server is incapable > of determining that the client is checking for the presence of "string". > However, what interests me is if any of these protocols also support > unlinkable queries, such that a client making multiple queries for the > presence of "string" does not reveal to the server over a set of queries > that they are checking for the presence of the same string in each query, > even if the server is incapable of determining which specific string the > client is checking for the presence of. > > I have been looking at a few encrypted bloom filter protocols and I do not > fully understand them yet, but before I spend the required time to figure > one out I would like to make sure that it has this property. One potential > solution I can think of is perhaps the servers can keep copies of the items > which they index (which are themselves very small, around 128 bytes) and > every cycle (ie: ten minutes) they hash the items with a hashing function > keyed with a value computable by the client and the server (ie: the time in > UTC exactly ten minutes ago when the previous cycle started), and then add > these items to a new bloom filter and delete the previous bloom filter. Now > if clients query the encrypted bloom filter no more than once per cycle, I > believe unlinkability may be gained (if it was not there in the first > place), as by definition the server is incapable of determining which > object in the bloom filter than the client is checking for the presence of, > and the query sent by the > client must look different as it is technically querying for a > completely different object than it was in previous cycles. Are there any > flaw in this? > > Thanks! > _______________________________________________ > cryptography mailing list > [email protected] > http://lists.randombit.net/mailman/listinfo/cryptography >
_______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
