On Fri, Jul 19, 2019 at 01:32:01PM +0200, Antonin Houska wrote:
>Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote:
>
>> On Mon, Jul 15, 2019 at 06:11:41PM -0400, Bruce Momjian wrote:
>> >On Mon, Jul 15, 2019 at 11:05:30PM +0200, Tomas Vondra wrote:
>> >> On Mon, Jul 15, 2019 at 03:42:39PM -0400, Bruce Momjian wrote:
>> >> > On Sat, Jul 13, 2019 at 11:58:02PM +0200, Tomas Vondra wrote:
>> >> > > One extra thing we should consider is authenticated encryption. We can't
>> >> > > just encrypt the pages (no matter which AES mode is used - XTS/CBC/...),
>> >> > > as that does not provide integrity protection (i.e. can't detect when
>> >> > > the ciphertext was corrupted due to disk failure or intentionally). And
>> >> > > we can't quite rely on checksums, because that checksums the plaintext
>> >> > > and is stored encrypted.
>> >> >
>> >> > Uh, if someone modifies a few bytes of the page, we will decrypt it, but
>> >> > the checksum (per-page or WAL) will not match our decrypted output. How
>> >> > would they make it match the checksum without already knowing the key.
>> >> > I read [1] but could not see that explained.
>> >> >
>> >>
>> >> Our checksum is only 16 bits, so perhaps one way would be to just
>> >> generate 64k of randomly modified pages and hope one of them happens to
>> >> hit the right checksum value. Not sure how practical such attack is, but
>> >> it does require just filesystem access.
>> >
>> >Yes, that would work, and opens the question of whether our checksum is
>> >big enough for this, and if it is not, we need to find space for it,
>> >probably with a custom encrypted page format. :-( And that makes
>> >adding encryption offline almost impossible because you potentially have
>> >to move tuples around. Yuck!
>> >
>>
>> Right. We've been working on allowing to disable checksum online, and it
>> would be useful to allow something like that for encryption too I guess.
>> And without some sort of page-level flag that won't be possible, which
>> would be rather annoying.
>>
>> Not sure it needs to be in the page itself, though - that's pretty much
>> why I proposed to store metadata (IV, key ID, ...) for encryption in a
>> new fork. That would be a bit more flexible than storing it in the page
>> itself (e.g. different encryption schemes might easily store different
>> amounts of metadata).
>>
>> Maybe a new fork is way too complex solution, not sure.
>
>One problem of this new fork would be that contents of its buffer (the MAC
>values) is not determined until the corresponding buffers of the MAIN fork get
>encrypted. However encryption is performed by the storage layer (md.c), which
>is not expected to lock other buffers (such as those of the "MAC fork"), read
>their pages from disk or insert their WAL records.
>
>This is different from the FSM or VM forks whose buffers are only updated
>above the storage layer.
>
Yes, that seems like a valid issue :-(
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
