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 | 20190709201250.6hw654qakf7klewb@development обсуждение исходный текст |
Ответ на | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
|
Список | pgsql-hackers |
On Tue, Jul 09, 2019 at 03:50:39PM -0400, Bruce Momjian wrote: >On Tue, Jul 9, 2019 at 02:09:38PM -0400, Joe Conway wrote: >> On 7/9/19 11:11 AM, Bruce Momjian wrote: >> > Good point about nonce and IV. I wonder if running the nonce >> > through the cipher with the key makes it random enough to use as an >> > IV. >> >> Based on that NIST document it seems so. >> >> The trick will be to be 100% sure we never reuse a nonce that is used >> to produce the IV when using the same key. >> >> I think the potential to get that wrong (i.e. inadvertently reuse a >> nonce) would lead to using the second described method >> >> "The second method is to generate a random data block using a >> FIPS-approved random number generator." >> >> That method is what I am used to seeing. But with the second method >> we need to store the IV, with the first we could reproduce it if we >> select our initial nonce carefully. >> >> So thinking out loud, and perhaps you already said this Bruce, but I >> guess the input nonce used to generate the IV could be something like >> pg_class.oid and blocknum concatenated together with some delimiting >> character as long as we guarantee that we generate different keys in >> different databases. Then there would be no need to store the IV since >> we could reproduce it. > >Uh, yes, and no. Yes, we can use the pg_class.oid (since it has to >be preserved by pg_upgrade anyway), and the page number. However, >different databases can have the same pg_class.oid/page number >combination, so there would be duplication between databases. Now, you >might say let's add the pg_database.oid, but unfortunately, because of >the way we file-system-copy files from one database to another during >database creation (it doesn't go through shared buffers), we can't use >pg_database.oid as part of the nonce. > >My only idea here is that we actually decrypt/re-encrypted pages as we >copy them at the file system level during database creation to match the >new pg_database.oid. This would allow pg_database.oid in the nonce/IV. >(I think we will need to modify pg_upgrade to preserve pg_database.oid.) > Ot you could just encrypt them with a different key, and you would not need to make database OID part of the nonce. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: