On Wed, Jul 10, 2019 at 01:04:47PM -0400, Alvaro Herrera wrote: > On 2019-Jul-10, Bruce Momjian wrote: > > > * Using the LSN as part of the nonce fixes both problems, and has a > > third benefit: > > > > * We don't need to decrypt/re-encrypt during CREATE DATABASE since > > the page contents are the same in both places, and once one > > database changes its pages, it gets a new LSN, and hence a new > > nonce/IV. > > > > * For each change of an 8k page, you get a new nonce/IV, so you > > are not encrypting different data with the same nonce/IV > > > > * This avoids requiring pg_upgrade to preserve database oids. > > An ignorant question -- what is it that gets stored in the page for > decryption use, the nonce or the IV derived from it? I think if you > want to store the nonce, you'd have to store the database OID, because > otherwise how do you know which database OID to use to determine the > full nonce after cloning a database? You already have the table OID in > the catalog and the LSN in the page header, so you're only missing the > database OID. (Assuming you make the nonce be database OID || relation > OID || page LSN)
You are right that if you used the database oid in the nonce, you would need to decrypt/re-encrypt the data during CREATE DATABASE, or store the original database oid in the page. The new approach is that a single key would be used for all databases and the WAL, and use the LSN instead of the database oid, so there is no need to know which database originally encrypted the page --- any database can decrypt it. > Also, how are key changes handled? Do we need to store a key identifier > in each page? Uh, we have not started discussing that yet. I am thinking we might need to store the key identifier in the pg_class table and then create a command to re-encrypt tables. We can re-key a page at a time, but we would still need to know when all pages/tables are no longer using the old key, so doing it just at the table/index level seems appropriate. -- Bruce Momjian <br...@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 +