Hacker News new | ask | show | jobs
by GTP 1474 days ago
The problem is: is also the full query encrypted or just some values that are considered sensitive? I remember a research form some years ago showing that if an attacker is still able to see the SQL code can recover the content of the database by looking at the queries, the responses and "putting the pieces together". Now, if the target was to get the exact values inside the database (think about employees wages) it still required to observe a very big number of queries, but if you were interested in getting a reasonable interval for each value then the number of queries needed become small enough to be doable in practice.

Unfortunately I don't seem too be able to find this again, but a quick search turned out two papers that say that just encrypting your db isn't enough: [0], [1]. In particualr [1] doesn't seem to go into the details of how you could recover the data, but mentions that many operations as performed by "normal" databases leak information if performed over encrypted data. Maybe someone that is more familiar with Queryable Encryption can comment on this?

[0] https://www.cs.cornell.edu/~shmat/shmat_hotos17.pdf [1] https://www.microsoft.com/en-us/research/wp-content/uploads/...

2 comments

You're on the right track. I work in the data security space and while this is a cool release, it's not novel[0] and has been around for a while[1]. As a general rule of thumb, the first thing to check is if the provider is asking you to pass in your query in plain text AND without a local client (very important, because if you're sending data in plaintext, the threat model is now transitioning to a honest-but-curious model).

This is obviously not that. They're encrypting locally. However, Simon Oya & Dr. Kerschbaum's paper, https://arxiv.org/abs/2010.03465, demonstrate a fantastic efficient attack to recover keywords on most constructions without a lot of queries. It is yet to be seen how effective MongoDB's implementation will be.

This is a very interesting space but structural encryption is the right way to put the theory into good use.

Most of the other encryption mechanisms such as homomorphic, partially homomorphic, etc. are just too impractical or require very specific niche use cases to be useful.

There are other misnamed technology I've seen in marketing such as "polymorphic encryption" or "vaultless" - but most of these haven't had real research or cryptanalysis behind it.

[0] https://info.ionic.com/hubfs/IonicDotCom/Resources/Assets/Se... [1] https://eprint.iacr.org/2017/111.pdf

Thank you for the information. Just one question: what do you mean by "without a local client"?
At a very high level, there has to be some sort of client-side encryption before transmitting the query to the server. That's usually the basic premise, client-side encrypts then transmits to the server which operates and returns a result that (in a simple 2 party system), the client (and only the client) will be able to decrypt. That is usually how these types of encryption protocols work.

That's what I mean by a "local client," there has to be something on the client side and it cannot just be something that communicates over the internet to a server w/o some sort of local encryption first.

I like it. There is always a way to hack something. This is an additional layer of security that yes, can be also broken.