RE: Enquiry about TDE with PgSQL - Mailing list pgsql-general

Speaking for myself, not Quest, as an "interested observer", I think Markus summarized it REALLY well.

Unfortunately, like a lot of "overloaded" terms/standards,  "TDE", whatever it means, has become a "checkbox" item.

Clay Jackson
Database Solutions Sales Engineer
clay.jackson@quest.com
office  949-754-1203  mobile 425-802-9603

-----Original Message-----
From: Markus Wanner <markus@bluegap.ch>
Sent: Friday, October 31, 2025 4:39 PM
To: Bruce Momjian <bruce@momjian.us>; Kai Wagner <kai.wagner@percona.com>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>; Ron Johnson <ronljohnsonjr@gmail.com>; pgsql-general
<pgsql-general@postgresql.org>
Subject: Re: Enquiry about TDE with PgSQL

CAUTION: This email originated from outside of the organization. Do not follow guidance, click links, or open
attachmentsunless you recognize the sender and know the content is safe. 


It's always entertaining to read PCI DSS...

In the "guidance and purpose" column of page 95, the standard reads:

     Disk-level encryption typically encrypts the entire disk
     or partition using the same key, with all data
     automatically decrypted when the system runs or when
     an authorized user requests it.

Granted, there would be benefits from a more fine grained encryption, e.g. where you'd encrypt PAN data with a
differentkey. I guess that would be called column encryption. But I don't think any version of TDE implements it that
way.The best I've seen is per tablespace. 

Further:

     Many disk-encryption solutions [..] perform the appropriate
     cryptographic transformations without any special action by the user
     other than supplying a password or passphrase at system start-up or
     at the beginning of a session.

Well, isn't that exactly how TDE also works? It loads the key at start-up (of the database system, not the operating
system,but that's equivalent for dedicated database servers) and decrypts "without any special action by the user".
Otherwise,it would not be very transparent. 

     This provides no protection from a malicious individual that
     has already managed to gain access to a valid user account

I see a point here in possible separation of concerns. With a sysadmin being able to manage the system, but not having
(direct)access to the data. That's more of an obscurity rather than hard security, though (as the key likely is
somewherein memory fully accessible for a malicious sysadmin). Still potentially beneficial in combination with all the
auditingetc... 

So, my conclusions:


  * some potential process level security, no scientific security gains
  * most (if not all) existing TDE products on the market don't actually
    satisfy the stated purpose (or differ enough from disk-level
    encryption)
  * these look like unnecessary hurdles pushed into the standard by
    companies trying to shake off competitors who miss these (somewhat
    dubious) features
  * as an OSS project, it's still pointless to fight the standard and
    much more feasible to just implement that darn feature.

Best Regards,
Markus


On 10/31/25 15:54, Bruce Momjian wrote:
> On Fri, Oct 31, 2025 at 03:01:48PM +0100, Kai Wagner wrote:
>> As I personally believe, there is no real way around TDE in the
>> future, either by extensibility of the core (start with the storage
>> manager and move your way on from there), to make an extension
>> possible, or by directly adding it to the core, there are more reasons coming or are already on their way.
>>
>> With the PCI DSS v4.1 standard, one key rule to comply with is, that
>> "If PAN is
>
> Uh, I think you mean the 4.0.1 standard, which became active on
> January 1, 2025.  I am surprised this is only being mentioned now:
>
>
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblog
> .pcisecuritystandards.org%2Fjust-published-pci-dss-v4-0-1&data=05%7C02
> %7Cclay.jackson%40quest.com%7C85d5352e5f094dbc847908de18d6b603%7C91c36
> 9b51c9e439c989c1867ec606603%7C0%7C0%7C638975507657957194%7CUnknown%7CT
> WFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI
> sIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=i9KeBmcLhsLkzK%2F
> 9gCmvx7%2FXLXdxbwg5zrfS99ISt8o%3D&reserved=0
>
>       When will PCI DSS v4.0 be retired?
>
>       As with all new versions of PCI DSS, there will be a period where both
>       the current and updated version will be active at the same time.
> PCI DSS
> -->   v4.0 will be retired on 31 December 2024. After that point, PCI DSS
> -->   v4.0.1 will be the only active version of the standard supported
> --> by PCI
>       SSC.
>
> While it was active on Jan 1, it became effective on March 31, 2025:
>
>       Does PCI DSS v4.0.1 change the 31 March 2025 effective date for the new
>       requirements?
>
>       No. This limited revision does not impact the effective date of these
>       new requirements.
>
>> stored, it must be rendered unreadable". Of course there are other
>> ways, like tokenization, hashing etc. but this regulation is pushing
>> towards at rest encryption in the long run, and not only disk
>> encryption. We can dislike it, but we are already seeing the need
>> coming from large industries and companies that they cannot work
>> around this anymore, as the auditors doing the checkboxes do not
>> really care about "good alternatives", as they do not even
>> technically understand what this is about. They do compare postgres
>> simply against other already in use databases at these orgs (MySQL or
>> MongoDB), and as such, we are currently the only one that cannot be used in such a use case, at least not without
thewillingness of the auditor to make it happen. 
>
> I see the new specification that disk-level encryption is
> insufficient, starting on page 93 (page 97 in the PDF URL):
>
>
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> middlebury.edu%2Fsites%2Fdefault%2Ffiles%2F2025-01%2FPCI-DSS-v4_0_1.pd
> f%23page%3D97&data=05%7C02%7Cclay.jackson%40quest.com%7C85d5352e5f094d
> bc847908de18d6b603%7C91c369b51c9e439c989c1867ec606603%7C0%7C0%7C638975
> 507657992323%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwL
> jAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%
> 7C&sdata=mb5D5ywMtVHX%2BSGw5on4KK6aA7SxDq76QLCK%2Bi5K9Pc%3D&reserved=0
>
> -->   3.5.1.2 If disk-level or partition-level encryption (rather than
>       file-, column-, or field-level database encryption) is used to
>       render PAN unreadable, it is implemented only as follows:
>
>       . On removable electronic media
>
>       OR
>
>       . If used for non-removable electronic media, PAN is also
> -->   rendered unreadable via another mechanism that meets Requirement
>       3.5.1.
>
>       ...
>
>       While disk or partition encryption may still be present on these
>       types of devices, it cannot be the only mechanism used to protect
>       PAN stored on those systems. Any stored PAN must also be rendered
>       unreadable per Requirement 3.5.1-for example, through truncation
>       or a data-level encryption mechanism. Full disk encryption helps
>       to protect data in the event of physical loss of a disk and
>       therefore its use is appropriate only for removable electronic
>       media storage devices.
>
>       Purpose
>
>       Disk-level and partition-level encryption typically encrypts
>       the entire disk or partition using the same key, with all data
>       automatically decrypted when the system runs or when an
> authorized
> -->   user requests it. For this reason, disk-level encryption is not
> -->   appropriate to protect stored PAN on computers, laptops,
> --> servers,
>       storage arrays, or any other system that provides transparent
>       decryption upon user authentication.
>
> PAN is:
>
>
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> middlebury.edu%2Fsites%2Fdefault%2Ffiles%2F2025-01%2FPCI-DSS-v4_0_1.pd
> f%23page%3D391&data=05%7C02%7Cclay.jackson%40quest.com%7C85d5352e5f094
> dbc847908de18d6b603%7C91c369b51c9e439c989c1867ec606603%7C0%7C0%7C63897
> 5507658014907%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIw
> LjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C
> %7C&sdata=v8S4Nnt%2Bh0a%2BjVfuoNk3BYjbM5vMtsdpcCXSFVX38mk%3D&reserved=
> 0
>
>       PAN Acronym for "primary account number." Unique payment card
>       number (credit, debit, or prepaid cards, etc.) that identifies
>       the issuer and the cardholder account.
>
> So it seems we have somewhat of a stand-off, with the Postgres project
> questioning the value of TDE and the PCI writers doubling-down on
> specifying disk-level encryption as insufficient.
>
> The biggest possible downside of this standoff is that enterprises
> that need to meet PCI compliance specifications are forced to use
> specialized versions of Postgres or Postgres extensions that support TDE.
>
> The fact that it has been seven months since PCI 4.0.1 was effective,
> with little to no discussion or movement on adding TDE to community
> Postgres means to me that we are unlikely to see TDE added to
> community Postgres anytime soon.  I have a small hope that adding
> compression to the writing of temporary files will reduce the code
> changes needed to encrypt temporary files, thus reducing the amount of
> TDE code changes needed.
>