Greetings, * Yura Sokolov (y.soko...@postgrespro.ru) wrote: > В Чт, 21/10/2021 в 13:28 -0400, Stephen Frost пишет: > > 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. > > > > ..... > > > > 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. > > > > ..... > > > > 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. > > > > 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. > > 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
signature.asc
Description: PGP signature
