Date: Mon, 25 Oct 2021 12:12:27 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Yura Sokolov <y.sokolov@postgrespro.ru>
Cc: Sasasu <i@sasa.su>, Robert Haas <robertmhaas@gmail.com>,
	Andres Freund <andres@anarazel.de>,
	Bruce Momjian <bruce@momjian.us>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: XTS cipher mode for cluster file encryption
Message-ID: <20211025161227.GE20998@tamriel.snowman.net>
References: <20211015192248.GP20998@tamriel.snowman.net>
 <20211015212109.ugwjuhe4lzymnorg@alap3.anarazel.de>
 <CA+TgmoaMHLXrxOj1HA+K=Z_qqgZUOpfdto8+QiVXsfP0ds+ojw@mail.gmail.com>
 <4b73c57e-0941-9e66-ea7e-087793c4c927@sasa.su>
 <20211019185456.GV20998@tamriel.snowman.net>
 <46bc5203-0a3c-0426-e69f-5f2997648b35@sasa.su>
 <20211020122407.GW20998@tamriel.snowman.net>
 <d85f5865-1f5a-618e-7d92-92914a0f26b1@sasa.su>
 <20211021172812.GZ20998@tamriel.snowman.net>
 <48020c9811b72499aa5c4c4584b34ed33b75d1b0.camel@postgrespro.ru>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="CQL2Jiu9fsaVZZPj"
Content-Disposition: inline
In-Reply-To: <48020c9811b72499aa5c4c4584b34ed33b75d1b0.camel@postgrespro.ru>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
 <https://www.postgresql.org/message-id/20211025161227.GE20998%40tamriel.snowman.net>
Precedence: bulk


--CQL2Jiu9fsaVZZPj
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings,

* Yura Sokolov (y.sokolov@postgrespro.ru) wrote:
> =D0=92 =D0=A7=D1=82, 21/10/2021 =D0=B2 13:28 -0400, Stephen Frost =D0=BF=
=D0=B8=D1=88=D0=B5=D1=82:
> > I really don't think this is necessary.  Similar to PageSetChecksumCopy
> > and PageSetChecksumInplace, I'm sure we would have functions which are
> > called in the appropriate spots to do encryption (such as 'encrypt_page'
> > and 'encrypt_block' in the Cybertec patch) and folks could review those
> > in relative isolation to the rest.  Dealing with blocks in PG is already
> > pretty well handled, the infrastructure that needs to be added is around
> > handling temporary files and is being actively worked on ... if we could
> > move past this debate around if we should be adding support for XTS or
> > if only GCM-SIV would be accepted.
> >=20
> > .....
> >=20
> > No, the CTR approach isn't great because, as has been discussed quite a
> > bit already, using the LSN as the IV means that different data might be
> > re-encrypted with the same LSN and that's not an acceptable thing to
> > have happen with CTR.
> >=20
> > .....
> >=20
> > We've discussed at length how using CTR for heap isn't a good idea even
> > if we're using the LSN for the IV, while if we use XTS then we don't
> > have the issues that CTR has with IV re-use and using the LSN (plus
> > block number and perhaps other things).  Nothing in what has been
> > discussed here has really changed anything there that I can see and so
> > it's unclear to me why we continue to go round and round with it.
> >=20
>=20
> Instead of debatting XTS vs GCM-SIV I'd suggest Google's Adiantum [1][2]
> [3][4].

That sounds like a great thing to think about adding ... after we get
something in that's based on XTS.

> It is explicitely created to solve large block encryption issue - disk
> encryption. It is used to encrypt 4kb at whole, but in fact has no
> (practical) limit on block size: it is near-zero modified to encrypt 1kb
> or 8kb or 32kb.
>=20
> It has benefits of both XTS and GCM-SIV:
> - like GCM-SIV every bit of cipher text depends on every bit of plain text
> - therefore like GCM-SIV it is resistant to IV reuse: it is safe to reuse
>   LSN+reloid+blocknumber tuple as IV even for hint-bit changes since every
>   block's bit will change.

The advantage of GCM-SIV is that it provides integrity as well as
confidentiality.

> - like XTS it doesn't need to change plain text format and doesn't need in
>   additional Nonce/Auth Code.

Sure, in which case it's something that could potentially be added later
as another option in the future.  I don't think we'll always have just
one encryption method and it's good to generally think about what it
might look like to have others but I don't think it makes sense to try
and get everything in all at once.

Thanks,

Stephen

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

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

iQIcBAEBCgAGBQJhdtdqAAoJEO1sijiDR2RVHcMP/31foDLW70Tr/vLKF7Vrg+KC
PuuuIiKi9XBydfi7aNODC4UbmDtIPe+VSTsM4wsCopJggzvsV34GQk3j7GX2Dkgp
gcfFgwt1h9Z+W82ekxmnZPyk2X5CNML3ZAie+dRsXnBNZsBCgBpqtG3uUQlG3AUT
Rdtf35jHpHAMO6he5HtGO0aaNeBELbRL2CDa5gDH3S0s4q9oNUhIRpZjskwXZh8z
pTSivv6dg6Rn32ytJujQIb8gxUToXJ9Ble1t73CVziUSr4/z9QK1kO7aRjg9RoPP
ja+zQ4mWiL1ekbTq3DAFQBEOvIDJBK2CGR9G/wunVSXIcSaI5lKGzlqBtqp2X12k
41AWN9SWoJKq+KKzHrPvx9ZngNCDecCS9DX+Rrmo2Imd0I35bRmFIg9yU75GU9pZ
ogV7oCJA+bd/+f7yFBpwYoSxwQHxX30AF4H+xdipUU+kMcYyCH81edRAf3+cjfj/
XnC3LJ7EaUDlnAQxthJmksUQlnq1R4uBoDqNAGR/Fu6UPfpPGJhl8WXfyQ2zyfxs
2bdnQPlTqFsksN9z+UvwOdU0lwyHRymlpBDpOsu3yK1wL/ZX0tE0+3OvYsiXREHk
m+HR4RXKMB9qBlJC1QAdrahltfVakmhDmQCgfK4mNCB3cl8b6f31oJsCFaxB5Dq0
gP6HmTIKbnA2wIQlrOXu
=xBdr
-----END PGP SIGNATURE-----

--CQL2Jiu9fsaVZZPj--