Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
От | Tomas Vondra |
---|---|
Тема | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) |
Дата | |
Msg-id | 20190709214552.gwdip6lqgnhmqdir@development обсуждение исходный текст |
Ответ на | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Список | pgsql-hackers |
On Tue, Jul 09, 2019 at 05:31:49PM -0400, Alvaro Herrera wrote: >On 2019-Jul-09, Tomas Vondra wrote: > >> On Tue, Jul 09, 2019 at 05:06:45PM -0400, Alvaro Herrera wrote: >> > On 2019-Jul-09, Joe Conway wrote: >> > >> > > > Ot you could just encrypt them with a different key, and you would not >> > > > need to make database OID part of the nonce. >> > > >> > > Yeah that was pretty much exactly what I was trying to say above ;-) >> > >> > So you need to decrypt each file and encrypt again when doing CREATE >> > DATABASE? >> >> The question is whether we actually need to do that? > >I mean if the new database is supposed to be encrypted with key B, you >can't just copy the files from the other database, since they are >encrypted with key A, right? Even if you consider that both copies of >each table have the same OID and each block has the same nonce. > Sure, if the databases are supposed to be encrypted with different keys, then we may need to re-encrypt the files. I don't see a way around that, but maybe we could use the scheme with master key somehow. >> Do we change OIDs of relations when creating the database? If not, we >> don't need to re-encrypt because having copies of the same block >> encrypted with the same nonce is not an issue (just like copying >> encrypted files is not an issue). > >Are you thinking that the files can be decrypted by the two keys >somehow? > No, I was kinda assuming the database will start with the same key, but that might have been a silly idea. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: