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
