Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
От | Bruce Momjian |
---|---|
Тема | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) |
Дата | |
Msg-id | 20190709145221.3ir2kszci45byppo@momjian.us обсуждение исходный текст |
Ответ на | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
Список | pgsql-hackers |
On Tue, Jul 9, 2019 at 10:34:06AM +0200, Tomas Vondra wrote: > > 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?). Storing the nonce on each 8k page is going to add complexity, so I am trying to figure out if it is a security requirement. -- Bruce Momjian <bruce@momjian.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 +
В списке pgsql-hackers по дате отправления: