Greetings, * Craig Ringer (cr...@2ndquadrant.com) wrote: > On Wed, 9 Oct 2019 at 22:30, Stephen Frost <sfr...@snowman.net> wrote: > > - All decryption happens in a given backend when it's sending data to > > the client > > That is not what I think of as TDE. But upon review, it looks like I'm > wrong, and the usual usage of TDE is for server-side-only encryption > at-rest.
Yes, that's typically what TDE is, at least in the relational DBMS world. > But when I'm asked about TDE, people are generally actually asking for data > that's encrypted at rest and in transit, where the client driver is > responsible for data encryption/decryption transparently to the > application. The server is expected to be able to mark columns as > encrypted, so it can report the column's true datatype while storing a > bytea-like encrypted value for it instead. In this case the server does not > know the column encryption/decryption key at all, and it cannot perform any > operations on the data except for input and output. This is definitely also a thing though I'm not sure what it's called, exactly. Having everything happen on the client side is also, certainly, a better solution as it removes the risk of root on the database server being able to gain access to the data. This is also what I recommend in a lot of situations- have the client side application handle the encryption/decryption, working with a vaulting solution ideally, but it'd definitely be neat to add this as a capability to PG. > Some people ask for indexable encrypted columns, but I tend to explain to > them how impractical and inefficient that is. You can support hash indexes > if you don't salt the encrypted data, but that greatly weakens the > encryption by allowing attackers to use dictionary attacks and other brute > force techniques efficiently. And you can't support b-tree > and < without > very complex encryption schemes ( > https://en.wikipedia.org/wiki/Homomorphic_encryption). I'm not sure why you wouldn't salt the hash..? That's pretty important, imv, and, of course, you have to store the salt but that shouldn't be that big of a deal, I wouldn't think. Agreed that you can't support b-tree (even with complex encryption schemes..., I've read some papers about how just </> is enough to be able to glean a good bit of info from, not super relevant to the overall discussion here so I won't go hunt them down right now, but if there's interest, I can try to do so). > I see quite a lot of demand for this column level driver-assisted > encryption. I think it'd actually be quite simple for the PostgreSQL server > to provide support for it too, since most of the work is done by the > driver. But I won't go into the design here since this thread appears to be > about encryption at rest only, fully server-side. Yes, that's what this thread is about, but I very much like the idea of driver-assisted encryption on the client side and would love it if someone had time to work on it. Thanks, Stephen
signature.asc
Description: PGP signature