On 7/9/19 4:34 AM, Tomas Vondra wrote: > On Mon, Jul 08, 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. >>For WAL I think it would be the WAL segment number. It would be nice >>to mix that with the "Database system identifier:", but are these the >>same on primary and replicas? >> > > Can't we just store the nonce somewhere? What if for encrypted pages we > only use/encrypt (8kB - X bytes), where X bytes is just enough to store > the nonce and maybe some other encryption metadata (key ID?). > > This would be similar to the "special" area on a page, except that that > relies on page header which is encrypted (and thus not accessible before > decrypting the page). > > So encryption would: > > 1) encrypt the (8kB - X bytes) with nonce suitable for the used > encryption mode (sequence, random, ...) > > 2) store the nonce / key ID etc. to the reserved space > > and encryption would > > 1) look at the encryption metadata at the end (nonce, key ....) > > 2) decrypt the page using that info
That is pretty much what I had been envisioning. > Or maybe we could define a new relation fork for encrypted relations, > storing all this metadata (not sure if we need that just for the main > fork or for all forks including vm, fsm ...)? I like the idea of a fork if it is workable. Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
signature.asc
Description: OpenPGP digital signature
