Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On Mon, Jul 8, 2019 at 06:45:50PM -0400, Bruce Momjian wrote:
> On Mon, Jul 8, 2019 at 06:23:13PM -0400, Bruce Momjian wrote:
> > Yes, 'postgres' can be used to create a nice md5 rainbow table that
> > works on many servers --- good point. Are rainbow tables possible with
> > something like AES?
> >
> > > I appreciate that *some* of this might not be completely relevant for
> > > the way a nonce is used in cryptography, but I'd be very surprised to
> > > have a cryptographer tell me that a deterministic nonce didn't have
> > > similar issues or didn't reduce the value of the nonce significantly.
> >
> > This post:
> >
> > https://stackoverflow.com/questions/36760973/why-is-random-iv-fine-for-aes-cbc-but-not-for-aes-gcm
> >
> > says:
> >
> > GCM is a variation on Counter Mode (CTR). As you say, with any variant
> > of Counter Mode, it is essential that the Nonce is not repeated with
> > the same key. Hence CTR mode Nonces often include either a counter or
> > a timer element: something that is guaranteed not to repeat over the
> > lifetime of the key.
> >
> > CTR is what we use for WAL. 8k pages, we would use CBC, which says we
> > need a random nonce. I need to dig deeper into ECB mode attack.
>
> Looking here:
>
> https://stackoverflow.com/questions/36760973/why-is-random-iv-fine-for-aes-cbc-but-not-for-aes-gcm
>
> I think the issues is that we can't use a _counter_ for the nonce since
> each page-0 of each table would use the same nonce, and each page-1,
> etc. I assume we would use the table oid and page number as the nonce.
> We can't use the database oid since we copy the files from one database
> to another via file system copy and not through the shared buffer cache
> where they would be re encrypted. Using relfilenode seems dangerous.

FYI, pg_upgrade already preserves the pg_class.oid, which is why I
recommended it over pg_class.relfilenode:

https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/bin/pg_upgrade/pg_upgrade.c;h=ff78929707ef12699a7579274693f6020c54c755;hb=HEAD#l14

We control all assignments of pg_class.oid (and relfilenode) so toast
oids are the same between old and new clusters. This is important
because toast oids are stored as toast pointers in user tables.

While pg_class.oid and pg_class.relfilenode are initially the same
in a cluster, they can diverge due to CLUSTER, REINDEX, or VACUUM
FULL. In the new cluster, pg_class.oid and pg_class.relfilenode will
be the same and will match the old pg_class.oid value. Because of
this, old/new pg_class.relfilenode values will not match if CLUSTER,
REINDEX, or VACUUM FULL have been performed in the old cluster.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +