Cryptography Could authors of Signal discovery service code running in SGX enclave have predicted correctly how to defend against cache side channels before Spectre was known? |
- Could authors of Signal discovery service code running in SGX enclave have predicted correctly how to defend against cache side channels before Spectre was known?
- New to the concept of public key cryptography. I have a question.
- Outsourceable key derivation
- Help with 64-bit len message decryption
| Posted: 03 Feb 2018 03:10 PM PST Wasn't sure if r/crypto or r/netsec was more appropriate for this. Long time ago, Signal was using peer/contact discovery using bloom filters where the bloom filters were stored by server and the server used the hashed phone numbers to check against the bloom filter. The obvious drawback of this is that it's very easy to bruteforce all possible phone numbers and compare them to bloom filter. So they decided to store and run the actual code along with private keys in a SGX enclave. The source code is here. The code's design was partially provably secure under the Oblivious RAM model. Since the announcement of Spectre vulnerability there were some proof-of-concepts showing that Spectre also affects code running in SGX enclave. However, it seems by looking at the code (and it's also mentioned in the blog article), that they seem to avoid the side-channel leaks in caches just by always touching all the cache lines when looking through the buckets before giving the final answer. I'm trying to figure out whether their precautions work as a defense against Spectre or not. So far for me it seems that yes, mostly that it would work and for the vulnerability to work you'd need a specific gadget in the SGX code to leak data (which probably also would be could be countered by evicting the cache lines when deterministically touching them). [link] [comments]  |
| New to the concept of public key cryptography. I have a question. Posted: 03 Feb 2018 11:25 AM PST From what I understand, public key cryptography allows for the transfer of encrypted data while "hiding" (for lack of a better term) the private key. The public key is used to encrypt, the private key to decrypt. My question is, when using asymmetric encryption in GNUPG for example, how is the recipient able to decrypt the data sent? Do they use the same private key the sender has, or is the recipient's private key also able to decrypt the data? How exactly does the decryption process work if the private key is hidden and unknown? [link] [comments]  |
| Posted: 03 Feb 2018 05:52 AM PST Is it possible to delegate a very slow key derivation to an untrusted party with lots of compute resources? Let's say I want to have an easy to remember secret, a single word (low entropy). I want to salt it, say with my full name, and derive a key from it. Because it's low entropy, the key derivation function must be very slow (eg, scrypt with parameters cranked up ridiculously high such that it would take a GPU cluster hours to derive the key). Is there a way to introduce some kind of blinding factor into the key derivation algorithm such that the untrusted party never learns the entropy or the actual derived key (and I can remove the blinding factor with minimal resources?) I suppose this would be homomorphic encryption? Edit: occurs to me that having to remember more information to remove the blinding factor would defeat the purpose of this scheme. So I'm guessing it is impossible, but maybe there's some other way. Edit: Deriving the key a 2nd time could use a different blinding factor so I think it should be possible. [link] [comments]  |
| Help with 64-bit len message decryption Posted: 03 Feb 2018 09:19 AM PST Found this playlist on spotify named "inconceivable" with the description "471a6b779c576b8db6c3344ed37c1df8f1772616bab93507295cb1506f4e22e4." I tried hex and dividing it up and check against md5 hashes but neither works. Any ideas? Could there be two layers of traditional algos? [link] [comments]  |
| You are subscribed to email updates from Cryptography news and discussions. To stop receiving these emails, you may unsubscribe now. | Email delivery powered by Google |
| Google, 1600 Amphitheatre Parkway, Mountain View, CA 94043, United States | |
No comments:
Post a Comment