Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1vEr99-001pib-MN for pgsql-general@arkaria.postgresql.org; Fri, 31 Oct 2025 15:34:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1vEr98-00Flos-Gl for pgsql-general@arkaria.postgresql.org; Fri, 31 Oct 2025 15:34:33 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1vEr98-00FloH-6N for pgsql-general@lists.postgresql.org; Fri, 31 Oct 2025 15:34:33 +0000 Received: from momjian.us ([72.94.173.45]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vEr95-004l1J-1d for pgsql-general@postgresql.org; Fri, 31 Oct 2025 15:34:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=momjian.us; s=2025010100; h=In-Reply-To:Content-Transfer-Encoding:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-ID:Content-Description; bh=gvlYc5xY4xj/trVdNlWCifJR6BRdxU0nSgoRG2rm9/w=; b=pO/QQn6IhzvvQ9hdEJa/2sKw8v Z1Kfy3quqM+0hvO7xU8qG9ktg+7NqI7U+16NwcnKGsD1G+9rojwPPAkGdc+A3k8iRWovDPDmfKAMl Lw01a9jKEqYSdB1D9SNXRHOpuGAi8A6cwF+ndbBSKjmbfGpV9u8OjeuQRIRdOp/gbkPPLkhmtmwHY k71lr/O8GSCTIK6HqC+j+o7HceZEx1whl+9pcURB5EDvQ4fEg3157oTSwDCRLKeUi40CfvoIhl0qK udo+PU40rfs3uHNrSozaOdVAvfo054YLtaBngt5eMmqwY97x4iu7Mulg1gTdQg77o0U1vj5sB2l09 +BFv6zUg==; Received: from bruce by momjian.us with local (Exim 4.98.2) (envelope-from ) id 1vEr94-00000005NSq-1LCi; Fri, 31 Oct 2025 11:34:30 -0400 Date: Fri, 31 Oct 2025 11:34:30 -0400 From: Bruce Momjian To: Greg Sabino Mullane Cc: Kai Wagner , Laurenz Albe , Ron Johnson , pgsql-general Subject: Re: Enquiry about TDE with PgSQL Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, Oct 31, 2025 at 11:25:04AM -0400, Greg Sabino Mullane wrote: > On Fri, Oct 31, 2025 at 10:54 AM Bruce Momjian wrote: > >         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. > > > Hmm, I read this a few times but still not sure what the technical objection > is. Yes, the entire disk is encrypted with the same key, but why is that > insufficient to protect things? Anyone care to guess what they are thinking > here? This is more an argument for security using layers. With storage encryption, the file system as visible is unencrypted, and backups of that file system can be unencrypted. Community Postgres relies on file system permissions to secure the data directory. You can argue that once file system permissions are bypassed, security is impossible, and agree with that, but some feel the extra step needed to pull the Postgres encryption key from memory is a security feature. And for backups, the Postgres encryption key might not be in memory. Of course, forcing encrypted backups is a solution, but an extra step. > 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. > > Not always a downside for the companies selling those specialized versions > though. Yes, no question they are happy. -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com Do not let urgent matters crowd out time for investment in the future.