Hi David,
> Working with Stephen, I am attempting to pick up some of the work that
> was left off with TDE and the key management infrastructure. I have
> rebased Bruce's KMS/TDE patches as they existed on the
> https://wiki.postgresql.org/wiki/Transparent_Data_Encryption wiki
> page, which are enclosed in this email.
I'm happy to see that the TDE effort was picked up.
> I would love to open a discussion about how to move forward and get
> some of these features built out. The historical threads here are
> quite long and complicated; is there a "current state" other than the
> wiki that reflects the general thinking on this feature? Any major
> developments in direction that would not be reflected in the code from
> May 2021?
The patches seem to be well documented and decomposed in small pieces.
That's good.
Unless somebody in the community remembers open questions/issues with
TDE that were never addressed I suggest simply iterating with our
usual testing/reviewing process. For now I'm going to change the
status of the CF entry [1] to "Waiting for Author" since the patchset
doesn't pass the CI [2].
One limitation of the design described on the wiki I see is that it
seems to heavily rely on AES:
> We will use Advanced Encryption Standard (AES) [4]. We will offer three key length options (128, 192, and 256-bits)
selectedat initdb time with --file-encryption-method
(there doesn't seem to be any mention of the hash/MAC algorithms,
that's odd). In the future we should be able to add the support of
alternative algorithms. The reason is that the algorithms can become
weak every 20 years or so, and the preferred algorithms may also
depend on the region. This should NOT be implemented in this
particular patchset, but the design shouldn't prevent from
implementing this in the future.
[1]: https://commitfest.postgresql.org/40/3985/
[2]: http://cfbot.cputube.org/
--
Best regards,
Aleksander Alekseev
