51–60 of 80 posts
Any plans to support mongodb?
We are hoping to leverage their recently released Queryable Encryption feature [1], but the key management is tricky.
Any plans to support mongodb?
We do plan to support MongoDB! Right now we are wrapping up DynamoDB, and mongo is next after. We are hoping to leverage their recently released Queryable Encryption feature [1], but the key management is tricky. [1] https://www.mongodb.com/products/queryable-encryption
Earlier quoted context omitted.
We do plan to support MongoDB! Right now we are wrapping up DynamoDB, and mongo is next after. We are hoping to leverage their recently released Queryable Encryption feature [1], but the key management is tricky. [1] https://www.mongodb.com/products/queryable-encryption
15 yrs experience with Mongo - if you want some help (contract work) please contact me dan.miller at eye0.com
How did you solve range queries? Prefix/suffix queries? Index performance? Aggregation on database end?
The short answer is we haven't fully solved it yet. We have two modes we can operate in - directly encrypting in the database, or doing just-in-time encryption as the query results come back. For the former most queries other than direct comparison won't work - we have some early work started on using both homomorphic encryption [1] and format-preserving masking to help there. With JIT response encryption none of tha…
Earlier quoted context omitted.
The short answer is we haven't fully solved it yet. We have two modes we can operate in - directly encrypting in the database, or doing just-in-time encryption as the query results come back. For the former most queries other than direct comparison won't work - we have some early work started on using both homomorphic encryption [1] and format-preserving masking to help there. With JIT response encryption none of tha…
yeah, FHE isn't, yet, something that can be used in a busy production env. At best I'd say it's a specialized tool, though in my mind it's a toy solution - can work for n=1, possibly for n<(low numbers) but not for large N.
From my experience you better have dedicated views for different stakeholders and your problem is solved without those downsides.
Idk as you loose the index and several operators your database might get useless and this solution would not scale well. From my experience you better have dedicated views for different stakeholders and your problem is solved without those downsides.
Custom views can help, but it does mean you're dealing with access controls directly in the database which can be hard to manage. And the database is fully exposed through backups or engineers with server access.
Idk as you loose the index and several operators your database might get useless and this solution would not scale well. From my experience you better have dedicated views for different stakeholders and your problem is solved without those downsides.
Idk as you loose the index and several operators your database might get useless and this solution would not scale well. From my experience you better have dedicated views for different stakeholders and your problem is solved without those downsides.
That may not be a correct assumption for ALL systems, but it's a safe assumption for A LOT of systems.
OP this is seriously cool, nicely done.
Any plans to support mongodb?