Re: [cryptography] Intel RNG - RdSeed
If you thought RdRand caused a lot of chatter on this list, we've just announced a new sister instruction.. RdSeed. It's here.. http://software.intel.com/file/45207 RdSeed is SP800-90B &C and X9.82 parts 2 & 4 compliant in the XOR construction. But they're all draft specs so things could change. RdSeed is to RdRand as /dev/random is to /dev/urandom. It returns 100% entropy (minus epsilon if you're picky). Since it is dependent on the supply of entropy and has quite a conservative conditioning ratio, its maximum throughput is less than that of RdRand. We haven't released anything other documentation on this yet, so until we do, this is as good a place to ask questions as any. DJ ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] encrypted bloom filter protocols with unlinkable queries
On 07/20/2012 10:41 PM, cryptoquesti...@safe-mail.net wrote: > 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 t he > 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 > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography > This would work only if you trust the server not to be malicious. I can tell you my "solution" to this. My PhD project involves an encrypted bloom filter that encodes client data. This bloom filter is then broadcast to all users so the queries are done client-side and no information is leaked by this process. The protocol works because my bloom filter is relatively small. If you can't share the whole bloom filter I'm thinking that maybe your client can do fake queries, retrieving a big enough part of the BF so it's hard to guess your real queries. You could also store the string in several different ways inside the BF so you have several ways to check for the same string and therefore no information can be inferred by looking at your queries. Regards, Alfred ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] encrypted bloom filter protocols with unlinkable queries
Never trust that the server delete data. - Sent from my tablet Den 21 jul 2012 11:15 skrev : > 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 > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography > ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] encrypted bloom filter protocols with unlinkable queries
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 cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
