On Tue, Jul 3, 2018 at 7:16 AM, Nico Williams <n...@cryptonector.com> wrote: > On Mon, Jul 02, 2018 at 06:22:46PM +0900, Masahiko Sawada wrote: >> On Fri, Jun 22, 2018 at 2:31 PM, Tsunakawa, Takayuki >> <tsunakawa.ta...@jp.fujitsu.com> wrote: >> > From: Nico Williams [mailto:n...@cryptonector.com] >> > >> >> One shortcoming of relying on OS functionality for protection against >> >> malicious storage is that not all OSes may provide such functionality. >> >> This could be an argument for implementing full, transparent encryption >> >> for an entire DB in the postgres server. Not a very compelling >> >> argument, but that's just my opinion -- reasonable people could differ >> >> on this. >> > >> > Yes, this is one reason I developed TDE in our product. And >> > in-database encryption allows optimization by encrypting only user >> > data. > > You're likely getting some things terribly wrong. E.g., integrity > protection. Most likely you're getting a false sense of security. > >> Me too. In-database encryption is helpful in practice. I think 1) and >> 2) seem to cover the thread models which the data encryption in >> database needs to defend. > > Yes, but piecemeal encryption seems like a bad idea to me. >
What do you mean by "piecemeal encryption"? Is it not-whole database encryption such as per-table or per-tablespace? If so could you please elaborate on the reason why you think so? Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
