Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dKmns-0004pH-S1 for pgsql-hackers@arkaria.postgresql.org; Tue, 13 Jun 2017 14:28:21 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dKmns-00065F-EU for pgsql-hackers@arkaria.postgresql.org; Tue, 13 Jun 2017 14:28:20 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dKmnr-000643-3t for pgsql-hackers@postgresql.org; Tue, 13 Jun 2017 14:28:19 +0000 Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dKmno-0004xs-Gz for pgsql-hackers@postgresql.org; Tue, 13 Jun 2017 14:28:17 +0000 Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id B9E6820AB3; Tue, 13 Jun 2017 10:28:15 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Tue, 13 Jun 2017 10:28:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=k+gIqlOiZ6BOrS8O/LeGx0Yj0xQhvWfDzRNu7Y8Sjc8=; b=YWCx5a5Q o8VlhDltshagFU3XYskUKNgUGoReNiAgZ7x2o2HA81rZ520+f0baIBmNKFltp5PA fnyZ97x3K36fH5SwffzmuLcSbwaYmkvHn9AgYK5SuXpu2f7imKw+pSCPTL1qMNgT 88Ndr0JOC+7Zm3Vm5iw68S/qMzKN4nbtk7uWCqqMLQD39xiNqmhmFwT7ZqGM+wWi 3sn5fWW5p+AFa+Be7spJvClm7RW6jJD9NY/wUuGroV517gjAMCHG0CkGD3TznLbd EJnSC2mBUKtMZSRU/4jBHgJB6mEQjr+jBmCvRwm+kTGZZHux+HVkln8vlf98sTer 8jlTK4Bu1csatg== X-ME-Sender: X-Sasl-enc: bzxC8nT2yuE+4Dk/CorG0+/ttmpIyYqu460do61/Go5z 1497364095 Received: from april.local (c-73-13-66-39.hsd1.pa.comcast.net [73.13.66.39]) by mail.messagingengine.com (Postfix) with ESMTPA id 6F7AA24767; Tue, 13 Jun 2017 10:28:15 -0400 (EDT) Subject: Re: WIP: Data at rest encryption To: Stephen Frost , Ants Aasma References: <06b6db11-3a3f-4d24-6f57-450f96ecda84@2ndquadrant.com> <20170613132416.GD3151@tamriel.snowman.net> Cc: Robert Haas , PostgreSQL-development From: Peter Eisentraut Organization: 2ndQuadrant Message-ID: Date: Tue, 13 Jun 2017 10:28:14 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170613132416.GD3151@tamriel.snowman.net> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org On 6/13/17 09:24, Stephen Frost wrote: > but there are > use-cases where it'd be really nice to be able to have PG doing the > encryption instead of the filesystem because then you can do things like > backup the database, copy it somewhere else directly, and then restore > it using the regular PG mechanisms, as long as you have access to the > key. That's not something you can directly do with filesystem-level > encryption Interesting point. I wonder what the proper extent of "encryption at rest" should be. If you encrypt just on a file or block level, then someone looking at the data directory or a backup can still learn a number of things about the number of tables, transaction rates, various configuration settings, and so on. In the scenario of a sensitive application hosted on a shared SAN, I don't think that is good enough. Also, in the use case you describe, if you use pg_basebackup to make a direct encrypted copy of a data directory, I think that would mean you'd have to keep using the same key for all copies. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers