On Mon, Jul 8, 2019 at 06:45:50PM -0400, Bruce Momjian wrote: > On Mon, Jul 8, 2019 at 06:23:13PM -0400, Bruce Momjian wrote: > > Yes, 'postgres' can be used to create a nice md5 rainbow table that > > works on many servers --- good point. Are rainbow tables possible with > > something like AES? > > > > > I appreciate that *some* of this might not be completely relevant for > > > the way a nonce is used in cryptography, but I'd be very surprised to > > > have a cryptographer tell me that a deterministic nonce didn't have > > > similar issues or didn't reduce the value of the nonce significantly. > > > > This post: > > > > > > https://stackoverflow.com/questions/36760973/why-is-random-iv-fine-for-aes-cbc-but-not-for-aes-gcm > > > > says: > > > > GCM is a variation on Counter Mode (CTR). As you say, with any variant > > of Counter Mode, it is essential that the Nonce is not repeated with > > the same key. Hence CTR mode Nonces often include either a counter or > > a timer element: something that is guaranteed not to repeat over the > > lifetime of the key. > > > > CTR is what we use for WAL. 8k pages, we would use CBC, which says we > > need a random nonce. I need to dig deeper into ECB mode attack. > > Looking here: > > > https://stackoverflow.com/questions/36760973/why-is-random-iv-fine-for-aes-cbc-but-not-for-aes-gcm > > I think the issues is that we can't use a _counter_ for the nonce since > each page-0 of each table would use the same nonce, and each page-1, > etc. I assume we would use the table oid and page number as the nonce. > We can't use the database oid since we copy the files from one database > to another via file system copy and not through the shared buffer cache > where they would be re encrypted. Using relfilenode seems dangerous.
FYI, pg_upgrade already preserves the pg_class.oid, which is why I recommended it over pg_class.relfilenode: https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/bin/pg_upgrade/pg_upgrade.c;h=ff78929707ef12699a7579274693f6020c54c755;hb=HEAD#l14 We control all assignments of pg_class.oid (and relfilenode) so toast oids are the same between old and new clusters. This is important because toast oids are stored as toast pointers in user tables. While pg_class.oid and pg_class.relfilenode are initially the same in a cluster, they can diverge due to CLUSTER, REINDEX, or VACUUM FULL. In the new cluster, pg_class.oid and pg_class.relfilenode will be the same and will match the old pg_class.oid value. Because of this, old/new pg_class.relfilenode values will not match if CLUSTER, REINDEX, or VACUUM FULL have been performed in the old cluster. -- 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 +