From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Ryan Lambert <ryan(at)rustprooflabs(dot)com>, 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) |
Date: | 2019-07-10 11:23:28 |
Message-ID: | 435f3982-21cc-bc33-b9f5-dfc990ae5ed2@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 7/9/19 7:28 PM, Stephen Frost wrote:
> Greetings,
>
> * Joe Conway (mail(at)joeconway(dot)com) wrote:
>> On 7/9/19 5:42 PM, Tomas Vondra wrote:
>> > There are two basic ways to construct nonces - CSPRNG and sequences, and
>> > then a combination of both, i.e. one part is generated from a sequence
>> > and one randomly.
>> >
>> > FWIW not sure using OIDs as nonces directly is a good idea, as those are
>> > inherently low entropy data - how often do you see databases with OIDs
>> > above 1M or so? Probably not very often, and in most cases those are
>> > databases where those OIDs are for OIDs and large objects, so irrelevant
>> > for this purpose. I might be wrong but having a 96-bit nonce with maybe
>> > just 32bits of entrophy seems suspicious.
>> >
>> > That does not mean we can't use the OIDs at all, but maybe hashing them
>> > into a single 4B value, and then picking the remaining 8B randomly.
>> > Also, we have a "natural" sequence in the database - LSNs, maybe that
>> > would be a good source of nonces too?
>>
>> I think you missed the quoted part (upthread) from the NIST document:
>>
>> "There are two recommended methods for generating unpredictable IVs.
>> The first method is to apply the forward cipher function, under the
>> same key that is used for the encryption of the plaintext, to a
>> nonce. The nonce must be a data block that is unique to each
>> execution of the encryption operation. For example, the nonce may be
>> a counter, as described in Appendix B, or a message number. The
>> second method is to generate a random data block using a
>> FIPS-approved random number generator."
>>
>> That first method says a counter as input produces an acceptably
>> unpredictable IV as long as it is unique to each encryption operation.
>> If each page is going to be an "encryption operation", so as long as our
>> input nonce is unique for a given key, we should be ok. If the input
>> nonce is tableoid+pagenum and the key is different per database (at
>> least, hopefully different per tablespace too), we should be good to go,
>> at least from what I can see.
>
> What I think Tomas is getting at here is that we don't write a page only
> once.
>
> A nonce of tableoid+pagenum will only be unique the first time we write
> out that page. Seems unlikely that we're only going to be writing these
> pages once though- what we need is a nonce that's unique for *every
> write* of the 8k page, isn't it? As every write of the page is going to
> be encrypting something new.
Hmm, good point. I'm not entirely sure it would be required if the two
page versions don't exist at the same time, but I guess backups mean
that it would, so yeah.
> With sufficient randomness, we can at least be more likely to have a
> unique nonce for each 8K write. Including the LSN seems like it'd be a
> possible alternative.
Joe
--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2019-07-10 11:27:47 | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS) |
Previous Message | Magnus Hagander | 2019-07-10 09:42:34 | pg_checksums (or checksums in general) vs tableam |