5 ms·

Perhaps by using homomorphic encryption? http://en.wikipedia.org/wiki/Homomorphic_encryption http://en.wikipedia.org/wiki/Homomorphic_encryption

by onezeno 12y ago

taariqlewis 12y ago
It was my understanding that homomorphic encryption was not yet ready for deployment. I didn't see that mentioned in the too brief blog post.
michwill 12y ago
No. It is possible to do it without HE! Full HE is 10^12 slower than normal computations, so impractical yet. In our case, the actual computations are done on the client
- davidw 12y ago
  So if I have, say, 10,000 patients, and I want to sort them by name, or search for those whose names begin with 'D', I need to fetch them all first?
  - michwill 12y ago
    No, you don't fetch them all. In fact, we tested search over encrypted archives of linux kernel mailing list w/o downloading that :-)
    - michwill 12y ago
      The server knows which pieces of the trees are you reading. That's all it knows.
  - michwill 12y ago
    To be precise, when you dataset is large, you fetch about log(index_size)
    - tmd83 12y ago
      More than the size of the data read (which I'm not sure how big would actually be) I'm more concerned about the latency. Isn't a lot of normal db server side operation now a fetch-from-db + do-calculation-on-client type operation? And a compromise client can still pull data by running query against the server right? So is the primary improvement that one cannot use database tools to easily export the full dataset? If I know correctly isn't database with encryption support also do dumps and other full db operations encrypted too?
      - michwill 12y ago
        > I'm more concerned about the latency Very valid concern. That is the bottleneck, and that was the first thing we've checked. > Isn't a lot of normal db server side operation now a fetch-from-db + do-calculation-on-client type operation? Not if you want to find something. Calculation-on-client is probably html rendering etc. > And a compromise client can still pull data by running query against the server right? Yes, but it's ok if you have millions of users, each with his own private data. It would probably cost too much to break into each client's computer (imagine a million bitcoin wallers with 0.1 bitcoin each). Currently available databases, when used with encryption, store the key in memory. So, memory dump or mitm attack could help an attacker to collect the key.

Perhaps by using homomorphic encryption? http://en.wikipedia.org/wiki/Homomorphic_encryption http://en.wikipedia.org/wiki/Homomorphic_encryption

by onezeno 12y ago

Perhaps by using homomorphic encryption? http://en.wikipedia.org/wiki/Homomorphic_encryption http://en.wikipedia.org/wiki/Homomorphic_encryption

taariqlewis 12y ago

It was my understanding that homomorphic encryption was not yet ready for deployment. I didn't see that mentioned in the too brief blog post.

michwill 12y ago

No. It is possible to do it without HE! Full HE is 10^12 slower than normal computations, so impractical yet. In our case, the actual computations are done on the client

davidw 12y ago
So if I have, say, 10,000 patients, and I want to sort them by name, or search for those whose names begin with 'D', I need to fetch them all first?
- michwill 12y ago
  No, you don't fetch them all. In fact, we tested search over encrypted archives of linux kernel mailing list w/o downloading that :-)
  - michwill 12y ago
    The server knows which pieces of the trees are you reading. That's all it knows.
- michwill 12y ago
  To be precise, when you dataset is large, you fetch about log(index_size)
  - tmd83 12y ago
    More than the size of the data read (which I'm not sure how big would actually be) I'm more concerned about the latency. Isn't a lot of normal db server side operation now a fetch-from-db + do-calculation-on-client type operation? And a compromise client can still pull data by running query against the server right? So is the primary improvement that one cannot use database tools to easily export the full dataset? If I know correctly isn't database with encryption support also do dumps and other full db operations encrypted too?
    - michwill 12y ago
      > I'm more concerned about the latency Very valid concern. That is the bottleneck, and that was the first thing we've checked. > Isn't a lot of normal db server side operation now a fetch-from-db + do-calculation-on-client type operation? Not if you want to find something. Calculation-on-client is probably html rendering etc. > And a compromise client can still pull data by running query against the server right? Yes, but it's ok if you have millions of users, each with his own private data. It would probably cost too much to break into each client's computer (imagine a million bitcoin wallers with 0.1 bitcoin each). Currently available databases, when used with encryption, store the key in memory. So, memory dump or mitm attack could help an attacker to collect the key.