On 2021/10/20 02:54, Stephen Frost wrote: > I agree with Robert- using hooks for this really isn't realistic.
OK, I agree use hooks is too invasive. Just a whim, never mind.But If PG has a clear block-based IO API, TDE is much easier to understand. security people may lack database knowledge but they can understand block IO.
This will allow more people to join PG community. On 2021/10/20 02:54, Stephen Frost wrote: > Where would you store the tag for GCM without changes in core? If can add 32bit reserve field (in CGM is 28bits) will be best.data file size will increase 0.048% (if BLCKSZ = 8KiB), I think it is acceptable even for the user who does not use TDE. but need ondisk format change. If without of modify anything in core and doing GCM, the under-layer can write out a key fork, fsync(2) key fork with the same strategy for main fork. this is crash-safe. The consistency is ensured by WAL. (means wal_log_hints need set to on) Or the underlayer can re-struct the IO request. insert one IV block per 2730(=BLKSZ/IV_SIZE) data blocks. this method like the _mdfd_getseg() in md.c which split file by 1GiB. No perception in the upper layers.
Both of them can use cache to reduce performance downgrade.for WAL encryption, the CybertecDB implement is correct. we can not write any extra data without adding a reserved field in core. because can not guarantee consistency. If use GCM for WAL encryption must disable HMAC verification.
* only shows the possibility, not mean anyone should implement TDE in that way.
* blahblah
OpenPGP_0x4E72AF09097DAE2E.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
