RE: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

Поиск
Список
Период
Сортировка
От Moon, Insung
Тема RE: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)
Дата
Msg-id 007a01d4be7b$da280e20$8e782a60$@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)  (Ibrar Ahmed <ibrar.ahmad@gmail.com>)
Ответы Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)  (Masahiko Sawada <sawada.mshk@gmail.com>)
Список pgsql-hackers
Dear Ibrar Ahmed.

From: Ibrar Ahmed [mailto:ibrar.ahmad@gmail.com]
Sent: Thursday, February 07, 2019 4:09 AM
To: Moon, Insung
Cc: Tom Lane; PostgreSQL-development
Subject: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)


On Tue, Jul 3, 2018 at 5:37 PM Moon, Insung <Moon_Insung_i3@lab.ntt.co.jp> wrote:
Dear Tom Lane.

> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Monday, June 18, 2018 11:52 PM
> To: Robert Haas
> Cc: Joe Conway; Masahiko Sawada; Moon, Insung; PostgreSQL-development
> Subject: Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)
>
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Mon, Jun 18, 2018 at 10:12 AM, Joe Conway <mail@joeconway.com> wrote:
> >> Not necessarily. Our pages probably have enough predictable bytes to
> >> aid cryptanalysis, compared to user data in a column which might not
> >> be very predicable.
>
> > Really?  I would guess that the amount of entropy in a page is WAY
> > higher than in an individual column value.
>
> Depending on the specifics of the encryption scheme, having some amount of known (or guessable) plaintext may allow
breaking
> the cipher, even if much of the plaintext is not known.  This is cryptology 101, really.
>
> At the same time, having to have a bunch of independently-decipherable short field values is not real secure either,
especially
> if they're known to all be encrypted with the same key.  But what you know or can guess about the plaintext in such
cases
> would be target-specific, rather than an attack that could be built once and used against any PG database.

> > Yes. If there is known to guessable data of encrypted data, maybe there is a  possibility of decrypting the
encrypteddata. 
> >
> > But would it be safe to use an additional encryption mode such as GCM or XFS to solve this problem?
> > (Do not use the same IV)
> > Thank you and Best regards.
> > Moon.
>
> >
> >                       regards, tom lane





> Hi Moon,
>
> Have you done progress on that patch? I am thinking to work on the project and found that you are already working on
it.The last message is almost six months old. I want to check with you that are you still working on that, if yes I can
helpon that by reviewing the patch etc. If you are not working on that anymore, can you share your done work (if
possible)?
> --
> Ibrar Ahmed

We are currently developing for TDE and integration KMS.
So, We will Also be prepared to start a new discussion with the PoC patch as soon as possible.

At currently, we have changed the development direction of a per-Tablespace unit by per-table
Also, currently researching how to associate with KMIP protocol related to the encryption key for integration with KMS.
We talked about this in the Unconference session of PGConf.ASIA,
And a week ago, we talked about the development direction of TDE and integration with KMS at FOSDEM PGDAY[1].

We will soon provide PoC with new discussions.

Regards.

[1] TRANSPARENT DATA ENCRYPTION IN POSTGRESQL AND INTEGRATION WITH KEY MANAGEMENT SERVICES

https://www.postgresql.eu/events/fosdem2019/schedule/session/2307-transparent-data-encryption-in-postgresql-and-integration-with-key-management-services/




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Feature: temporary materialized views
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Commit Fest 2019-01 is now closed