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