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