3 ms·

I was completely lost attempting to understand this at first but I think I kind of get it now based on the documentation on the website. However, some things se

I was completely lost attempting to understand this at first but I think I kind of get it now based on the documentation on the website. However, some things seem strange. If I have N items in my database, the key is length N bits. I million items = 1 million bit key. It is very likely that I am not understanding this correctly however. Does something translate a Log(N) sized "user" key to a one hot vector? item = key * database That sounds like loading the entire database every time. If true, I do understand how the system cannot possibly would not know which item was retrieved but not clear on how the entire database isn't loaded every time. "Cryptographic proof that the server is not spying..." I don't understand how this is possible. If the service is implemented to remember the key, perform the request and return the result how can cryptographic proof be provided. In any case, this definitely seems like a very cool and useful project. I struggle to understand / trust it a little but perhaps I'll eventually become comfortable with it.

neilmovva 4y ago
Thanks for checking it out! Responses inline: > That sounds like loading the entire database every time Yup, we do perform computation over the entire database for every read - there is zero correlation between the server's work and the client's query. We currently serve queries to a 1 GB database in under 1 second. For much larger databases (100+ GB), this becomes more a question of cost: we can stay fast (1 sec) with more expense, or go slower (e.g. 5 sec) and stay cheap. > Cryptographic proof that the server is not spying If you trust your client software [0], then you can be sure that your request isn't decrypted anywhere outside your device. Even a malicious Blyss server cannot determine your query, because it never got a chance to see it. [0] This level of security depends entirely on having a trusted client. Our client software is open source, and we plan to have it formally audited. We'll also publish signed desktop apps so you can be sure that you're running the same client every time.
- osigurdson 4y ago
  So, imagine your api endpoint looks like this: get_data(key): hahaGotTheKey = key result = do_complicated_homomorphic_stuff(key) hahaGotTheResult = result save(hahaGotTheKey, hahaGotTheResult) return result I guess you are saying the since the key is encrypted there is no way to know exactly what the user asked for. The result is encrypted so there is no way to know what it is. The only thing we know is the user asked for something and something was retrieved. Of course, if the key is encrypted and the data is encrypted, how is it differentiated from a regular kvs? i.e. cypherKey = encr(key) cypherData = encr(value) kvs.put(cypherKey, cypherData) Of course, I obviously do not understand it - this is merely a window into my flawed mental model.

neilmovva 4y ago

Thanks for checking it out! Responses inline: > That sounds like loading the entire database every time Yup, we do perform computation over the entire database for every read - there is zero correlation between the server's work and the client's query. We currently serve queries to a 1 GB database in under 1 second. For much larger databases (100+ GB), this becomes more a question of cost: we can stay fast (1 sec) with more expense, or go slower (e.g. 5 sec) and stay cheap. > Cryptographic proof that the server is not spying If you trust your client software [0], then you can be sure that your request isn't decrypted anywhere outside your device. Even a malicious Blyss server cannot determine your query, because it never got a chance to see it. [0] This level of security depends entirely on having a trusted client. Our client software is open source, and we plan to have it formally audited. We'll also publish signed desktop apps so you can be sure that you're running the same client every time.

osigurdson 4y ago
So, imagine your api endpoint looks like this: get_data(key): hahaGotTheKey = key result = do_complicated_homomorphic_stuff(key) hahaGotTheResult = result save(hahaGotTheKey, hahaGotTheResult) return result I guess you are saying the since the key is encrypted there is no way to know exactly what the user asked for. The result is encrypted so there is no way to know what it is. The only thing we know is the user asked for something and something was retrieved. Of course, if the key is encrypted and the data is encrypted, how is it differentiated from a regular kvs? i.e. cypherKey = encr(key) cypherData = encr(value) kvs.put(cypherKey, cypherData) Of course, I obviously do not understand it - this is merely a window into my flawed mental model.