Re: Transparent Data Encryption (TDE) and encrypted files

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Transparent Data Encryption (TDE) and encrypted files
Date: 2019-10-09 23:47:46
Message-ID: CAMsr+YF==YK8p8uFkYXp0o2sBscRzEP7ng91JazjJE=4wX5pVQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 9 Oct 2019 at 22:30, Stephen Frost <sfrost(at)snowman(dot)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.

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.

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 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.

--
Craig Ringer http://www.2ndQuadrant.com/
2ndQuadrant - PostgreSQL Solutions for the Enterprise

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2019-10-09 23:52:17 Re: pg_init
Previous Message Tom Lane 2019-10-09 23:41:54 Re: BUG #16045: vacuum_db crash and illegal memory alloc after pg_upgrade from PG11 to PG12