Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Stephen Frost <sfrost@snowman.net>, Joe Conway <mail@joeconway.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Antonin Houska <ah@cybertec.at>, Haribabu Kommi <kommi.haribabu@gmail.com>, "Moon, Insung" <Moon_Insung_i3@lab.ntt.co.jp>, Ibrar Ahmed <ibrar.ahmad@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-07-09T14:52:21Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Revamp the WAL record format.
- 2c03216d8311 9.5.0 cited
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 +