Date: Mon, 11 Jan 2021 15:52:28 -0500
From: Stephen Frost <sfrost@snowman.net>
To: Bruce Momjian <bruce@momjian.us>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>,
	Thomas Munro <thomas.munro@gmail.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>,
	Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
Subject: Re: Key management with tests
Message-ID: <20210111205227.GV27507@tamriel.snowman.net>
References: 
 <CA+hUKGL21_sf1gj2oxqGMEMJHxybZ_9v+9auz0_VDaDsUJZ+NQ@mail.gmail.com>
 <20210110145116.GE19555@momjian.us>
 <CAD21AoDOWmNwg4Tqc4JxuXXD0KYkHPhCeG=pHRO3NGDr3tryNQ@mail.gmail.com>
 <20210111172213.GE4320@momjian.us>
 <20210111175449.GR27507@tamriel.snowman.net>
 <20210111180423.GG4320@momjian.us>
 <20210111182326.GS27507@tamriel.snowman.net>
 <20210111190657.GH4320@momjian.us>
 <20210111191922.GT27507@tamriel.snowman.net>
 <20210111202243.GK4320@momjian.us>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="ZeKMDbS2zcU1/kmZ"
Content-Disposition: inline
In-Reply-To: <20210111202243.GK4320@momjian.us>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk


--ZeKMDbS2zcU1/kmZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings,

* Bruce Momjian (bruce@momjian.us) wrote:
> On Mon, Jan 11, 2021 at 02:19:22PM -0500, Stephen Frost wrote:
> > outputs from the GCM encryption and is what provides the integrity /
> > authentication of the encrypted data to be able to detect if it's been
> > modified.  Unfortunately, while the page checksum will continue to be
> > used and available for checking against disk corruption, it's not
> > sufficient.  Hence, ideally, we'd find a spot to stick the 128-bit tag
> > on each page.
>=20
> Agreed.  Would checksums be of any value with GCM?

The value would be to allow testing of the database integrity, to the
amount allowed by the checksum, to be done without having access to the
encryption keys, and because there's not much else we'd be using those
bits for if we didn't.

> > Given that, clearly, it's not possible to go from an unencrypted cluster
> > to an encrypted cluster without rewriting the entire cluster, we aren't
> > bound to maintain the on-disk page format, we should be able to
> > accomadate including the tag somewhere.  Unfortuantely, it doesn't seem
> > quite as trivial as I'd hoped since there are parts of the code which
> > make assumptions about the page beyond perhaps what they should be, but
> > I'm still hopeful that it won't be *too* hard to do.
>=20
> OK, thanks.  Are there other page improvements we should make when we
> are requiring a page rewrite?

This is an interesting question but ultimately I don't think we should
be looking at this from the perspective of allowing arbitrary changes to
the page format.  The challenge is that much of the page format, today,
is defined by a C struct and changing the way that works would require a
great deal of code to be modified and turn this into a massive effort,
assuming we wish to have the same compiled binary able to work with both
unencrypted and encrypted clusters, which I do believe is a requirement.

The thought that I had was to, instead, try to figure out if we could
fudge some space by, say, putting a 128-bit 'hole' at the end of the
page and just move pd_special back, effectively making the page seem
'smaller' to all of the code that uses it, except for the code that
knows how to do the decryption.  I ran into some trouble with that but
haven't quite sorted out what happened yet.  Other ideas would be to put
it before pd_special, or maybe somewhere else, but a lot depends on the
code's expectations.

Thanks,

Stephen

--ZeKMDbS2zcU1/kmZ
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJf/LqLAAoJEO1sijiDR2RVjN8QAMJhZxj78bOzZ8Duy5RICKWa
jvNDHZaFJaaiQCKRmcl6WzkoNM5FByzs1ZvU8/B3JYt9rfpE37bTow0R946QvlWt
UpNlytEYZiAat9qUbZp1vo6tFC4Td+FlvR12Wowj49jOyrtOkeQQE4b1tJ6XONgm
h7nEGdZOX4fGz+of3rxkPG8L0Imzpw588YHsU77+ucIVehm4i6rYjKl3XM3fjIQz
LvXx3iqJK+W4JsnhvRUFG5xJQ0DXFFTmRz9LMK3O2KjOeCU0HTDbJRG480kw3l6c
wCayAqPpWUyfYU67628LYTJIWh/WL4MaYj0i2md77ciu437AFOYS/NfbAW6veAHB
elVIVRapJW0UWpIXTb48nSKENFlqUswizVr24No37FCPWdfzo33RWTf8HTtNVmJn
ZLW4s8Xp9cz2fEgE3AbyWvUUaliShhCgjASbCpIpJRS78DRsuwIfAeUtKnDqSKNh
5buLZAFINKAVRk/4H9RtMs6slM/ZoiGJs8stBqbrp2Rj73HpgOWjcn7CJLgvLxpx
0O+qsllfB7MYSKZ9lf2KAki/j889r8qmLozj+L1PYwnWVMrJFhFYgeRRVnSFD2B5
w2iN8WI6qMcF4n1gwvZEInZZZbDNUtn/w5PDrakL2cwDue+uQpK88uEtKrvqVe0X
ccRdEjeNg1ajG8ZPUIln
=6ouX
-----END PGP SIGNATURE-----

--ZeKMDbS2zcU1/kmZ--