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

On Mon, Jul 08, 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.
>For WAL I think it would be the WAL segment number. It would be nice
>to mix that with the "Database system identifier:", but are these the
>same on primary and replicas?
>

Can't we just store the nonce somewhere? What if for encrypted pages we
only use/encrypt (8kB - X bytes), where X bytes is just enough to store
the nonce and maybe some other encryption metadata (key ID?).

This would be similar to the "special" area on a page, except that that
relies on page header which is encrypted (and thus not accessible before
decrypting the page).

So encryption would:

1) encrypt the (8kB - X bytes) with nonce suitable for the used
encryption mode (sequence, random, ...)

2) store the nonce / key ID etc. to the reserved space

and encryption would

1) look at the encryption metadata at the end (nonce, key ....)

2) decrypt the page using that info

Or maybe we could define a new relation fork for encrypted relations,
storing all this metadata (not sure if we need that just for the main
fork or for all forks including vm, fsm ...)?

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services