|From:||Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>|
|To:||Bruce Momjian <bruce(at)momjian(dot)us>|
|Cc:||Joe Conway <mail(at)joeconway(dot)com>, Ryan Lambert <ryan(at)rustprooflabs(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Antonin Houska <ah(at)cybertec(dot)at>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, "Moon, Insung" <Moon_Insung_i3(at)lab(dot)ntt(dot)co(dot)jp>, Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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.
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
|Next Message||Tom Lane||2019-07-09 20:15:38||Re: benchmarking Flex practices|
|Previous Message||Joe Conway||2019-07-09 20:11:39||Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)|