Live data from Hacker News

MongoDB Releases Queryable Encryption Preview

mongodb.com

51–60 of 69 posts

Re: MongoDB Releases Queryable Encryption Preview

#51
post #42

This feature is a result of MongoDB's acquisition of Aroki. It looks like a good product but we actually beat them to it with https://cipherstash.com/activestash CipherStash works with any Database and also supports Range queries and sorting/ordering. We do it in the application layer. Only supports Ruby so far but C#, Java, Python, Rust are in the works.

What about Go, or even Tcl, and Ocaml? Do you have pointers to docs that'd help OSS efforts in this department?

Not yet but that's a good suggestion! The core client code is Rust so additional languages are (mostly) just native bindings to Rust. We will be releasing the Rust SDK publicly soon and welcome contributions!

Re: MongoDB Releases Queryable Encryption Preview

#53
post #36

Earlier quoted context omitted.

It is less secure than your standard symmetric encryption. I guess they would use deterministic encryption in which 2 entries with same email address will have the same record string ( this leaks information to attacker ). Prefix search & sort can be achieved by using order preserving encryption. Not really sure about sub-string though.

I've researched order preserving encryption before but the tradeoffs (mainly that the attacker can tell the order and use that to narrow the search space) always seemed like high risk.

High risk compared to what? The alternative is absolutely no privacy (status quo) or no/limited functionality (not very useful). Seems like strictly better than having no privacy.

Re: MongoDB Releases Queryable Encryption Preview

#54

Help me understand this... It says it will support prefix search, substring search, and the like. Can anyone point me in the right direction on what the algorithm may be here? I don't get how you could do those things without making the encryption less secure and/or decrypting every record the fly. Another interesting use case I found that isn't mentioned here is sort. I've had customers ask me to be able to sort the…

Related video explaining encryption schemes to make encrypted data in a DB queryable: CryptDB: Processing Queries on an Encrypted Database https://youtu.be/xsaXMUelOEA?t=807

I was under the impression that cryptdb "encryption" was thoroughly broken. Am i mistaken?

E.g. googling i found http://cs.brown.edu/people/seny/pubs/edb.pdf

Re: MongoDB Releases Queryable Encryption Preview

#55
post #53

Earlier quoted context omitted.

I've researched order preserving encryption before but the tradeoffs (mainly that the attacker can tell the order and use that to narrow the search space) always seemed like high risk.

High risk compared to what? The alternative is absolutely no privacy (status quo) or no/limited functionality (not very useful). Seems like strictly better than having no privacy.

Using fake encryption is much riskier than no encryption, because if you think you are safe you will do unsafe things with your data. If you know you are unsafe then you will take appropriate precautions.

Re: MongoDB Releases Queryable Encryption Preview

#56
I call bullshit.

So let me get this right - its encrypted but you cansearch prefix and suffix?

So all the attacker has to do is do it one letter at a time, see if it starts with A, B, C, once they figure that out, go to the next letter and so on. (I presume that the DB is not supposed to be trusted since they make such a big fuss about only being decryptable on the client side)

Also there doesn't seem to be a whitepaper detailing algorithms or their threat model. Bitcoin scams try harder then this.

Re: MongoDB Releases Queryable Encryption Preview

#57
post #46

Earlier quoted context omitted.

Yeah, they contrast their method with homomorphic encryption, which makes me share your suspicion

Yeah, I've been looking for more information and I can't really see any indication as to how they are planning on implementing it. The whole thing seems more like marketing than actual innovation: searching encrypted data isn't that complicated if you are always dealing with the entire ciphertext, it's just another string in that use case.

> searching encrypted data isn't that complicated if you are always dealing with the entire ciphertext, it's just another string in that use case.

This isn't really true because there are multiple ciphertexts that can decode to the same plaintext in any modern encryption algorithm. If you skip that property you weaken the encryption. (Chosen plaintext attacks)

Re: MongoDB Releases Queryable Encryption Preview

#58
post #56

I call bullshit. So let me get this right - its encrypted but you cansearch prefix and suffix? So all the attacker has to do is do it one letter at a time, see if it starts with A, B, C, once they figure that out, go to the next letter and so on. (I presume that the DB is not supposed to be trusted since they make such a big fuss about only being decryptable on the client side) Also there doesn't seem to be a whitepa…

It’s already been mentioned that “Queryable Encryption was designed by MongoDB’s Advanced Cryptography Research Group, headed by Seny Kamara and Tarik Moataz" - are you calling bullshit on their work? What are your qualifications?

Re: MongoDB Releases Queryable Encryption Preview

#59
post #53

Earlier quoted context omitted.

I've researched order preserving encryption before but the tradeoffs (mainly that the attacker can tell the order and use that to narrow the search space) always seemed like high risk.

High risk compared to what? The alternative is absolutely no privacy (status quo) or no/limited functionality (not very useful). Seems like strictly better than having no privacy.

Depending on your compliance needs and the sensitivity of your data, "limited functionality" may be a reasonable tradeoff, though.

Re: MongoDB Releases Queryable Encryption Preview

#60
post #56

I call bullshit. So let me get this right - its encrypted but you cansearch prefix and suffix? So all the attacker has to do is do it one letter at a time, see if it starts with A, B, C, once they figure that out, go to the next letter and so on. (I presume that the DB is not supposed to be trusted since they make such a big fuss about only being decryptable on the client side) Also there doesn't seem to be a whitepa…

The use case you're outlining is someone already has access to the database. They can just do a find() in that case and get everything, no query required. You're basically describing an lz77 SSL hack that's like 20 years old, I'm pretty sure they would think of this.

The use case here is just "advanced encryption at rest". Encrypting at rest is one thing, but this means people are less likely to see PII by accident, for example.

Post reply on HN