Different keys per column / entity

[cesarsouza]

Hi there,

Is there any way that we could configure different keys or IVs per entity property (i.e. per table/column)?

I am asking this because this could be useful in the context of a multi-tenant application where each tenant would have a separate key to encrypt their own data.

If not, would you have a suggestion for something that could be used to ensure that tenants would be able to decrypt only their own data and nothing else?

[Eastrall]

Hi,

The library has been designed for having only encryption provider for all the database. I believe you will need to create your own encryption provider to achieve what you are trying to do.

As an example, let's say you have your encryption keys for each of your tenants stored somewhere (database, cloud, file system, other...).

If you create a new encryption provider you could load inside the construtor all the encryption keys during initialization. Then, just like in PR #12 that introduces a single IV per field, you could use the same mechanism to include a tenant ID (as a single byte or many bytes at the begining of your data during the encryption process and during reading process, you would read the first byte (or bytes) to know what is the tenant ID and finaly, use the correct key do decrypt the data.

⚠️ Note that is pure theory, I don't know if it would work and perform well in a real environment production.

[cesarsouza]

Hi, thanks a lot for the answer. Yes, I started doing something like this, I will update here if it works.

Cheers!

[cesarsouza]

Hi,

Just wanted to comment out that after evaluating the pros and cons of every single solution we have studied (the solution brought by this repository being one of them, alongside of our custom extensions) we decided to go with the Azure always encrypted with secure enclaves solution. It's not pleasant at all to implement, and it also didn't play well at all with our test scenarios (which were using sqlite at the moment) but in the long term, that was the kind of solution what would be in the best interest of our users.

We decided to take the hit back and go along with the azure solution. However, it would have been really nice to have a third party solution that could provide this kind of functionality out-of-the-box for databases other than SQL server. Guess that's a dreamland though, the SQL Server and Azure guys must have puta lot of effort to ensure this functionality was a killer for decision-making.

Cheers, Cesar

[Eastrall]

Hi, thank you for the feedback @cesarsouza, I appriciate. I'm glad to know that you have found a solution dispites the difficulty of implementation compared to my library. It is an interesting topic, and maybe on the future, if I have time, I will dig a little this issue and try to find a solution to this use case.

I will let this issue open and flagged and not loose track of it.

Good luck with your project.