Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Thu, Oct 10, 2019 at 10:40:37AM -0400, Stephen Frost wrote:
> > > Some people ask for indexable encrypted columns, but I tend to explain to
> > > them how impractical and inefficient that is. You can support hash indexes
> > > if you don't
On Thu, Oct 10, 2019 at 10:40:37AM -0400, Stephen Frost wrote:
> > Some people ask for indexable encrypted columns, but I tend to explain to
> > them how impractical and inefficient that is. You can support hash indexes
> > if you don't salt the encrypted data, but that greatly weakens the
> > encr
On Mon, Oct 14, 2019 at 3:42 PM Antonin Houska wrote:
>
> Masahiko Sawada wrote:
>
> > On Wed, Oct 9, 2019 at 3:57 PM Antonin Houska wrote:
> > >
> > > Moon, Insung wrote:
> > >
> > > v04-0011-Make-buffile.c-aware-of-encryption.patch in [1] changes
> > > buffile.c so
> > > that data is read an
Masahiko Sawada wrote:
> On Wed, Oct 9, 2019 at 3:57 PM Antonin Houska wrote:
> >
> > Moon, Insung wrote:
> >
> > v04-0011-Make-buffile.c-aware-of-encryption.patch in [1] changes buffile.c
> > so
> > that data is read and written in 8kB blocks if encryption is enabled. In
> > order
> > to rec
On Wed, Oct 9, 2019 at 3:57 PM Antonin Houska wrote:
>
> Moon, Insung wrote:
>
> > On Wed, Oct 9, 2019 at 2:42 PM Antonin Houska wrote:
> > >
> > > Moon, Insung wrote:
> > >
> > > > I also tried to generate IV using PID (32bit) + tempCounter (64bit) at
> > > > first, but in the worst-case PID a
Greetings,
* Craig Ringer (cr...@2ndquadrant.com) wrote:
> On Wed, 9 Oct 2019 at 22:30, Stephen Frost wrote:
> > - All decryption happens in a given backend when it's sending data to
> > the client
>
> That is not what I think of as TDE. But upon review, it looks like I'm
> wrong, and the usua
On Wed, 9 Oct 2019 at 22:30, Stephen Frost wrote:
>
> - All decryption happens in a given backend when it's sending data to
> the client
>
That is not what I think of as TDE. But upon review, it looks like I'm
wrong, and the usual usage of TDE is for server-side-only encryption
at-rest.
But w
On Mon, Oct 7, 2019 at 12:34:36PM -0400, Bruce Momjian wrote:
> On Mon, Oct 7, 2019 at 12:30:37PM -0400, Robert Haas wrote:
> > On Mon, Oct 7, 2019 at 11:48 AM Bruce Momjian wrote:
> > > Well, I am starting with the things I _know_ need encrypting, and am
> > > then waiting for others to tell me
Greetings,
* Magnus Hagander (mag...@hagander.net) wrote:
> On Thu, Oct 3, 2019 at 4:40 PM Stephen Frost wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> > > On Mon, Sep 30, 2019 at 5:26 PM Bruce Momjian wrote:
> > > > For full-cluster Transparent Data Encryption (TDE), the current plan
Moon, Insung wrote:
> On Wed, Oct 9, 2019 at 2:42 PM Antonin Houska wrote:
> >
> > Moon, Insung wrote:
> >
> > > I also tried to generate IV using PID (32bit) + tempCounter (64bit) at
> > > first, but in the worst-case PID and tempCounter are used in the same
> > > values.
> > > Therefore, the
Dear Antonin Houska.
Thank you for your attention to thie matter.
On Wed, Oct 9, 2019 at 2:42 PM Antonin Houska wrote:
>
> Moon, Insung wrote:
>
> > Hello.
> >
> > On Tue, Oct 8, 2019 at 8:52 PM Antonin Houska wrote:
> > >
> > > Robert Haas wrote:
> > >
> > > > On Mon, Oct 7, 2019 at 3:01 PM A
Moon, Insung wrote:
> Hello.
>
> On Tue, Oct 8, 2019 at 8:52 PM Antonin Houska wrote:
> >
> > Robert Haas wrote:
> >
> > > On Mon, Oct 7, 2019 at 3:01 PM Antonin Houska wrote:
> > > > However the design doesn't seem to be stable enough at the
> > > > moment for coding to make sense.
> > >
> >
Dear hackers.
First, I don't know which email thread should written a reply,
therefore using the first email thread.
Sorry about the inconvenience...
Sawada-san and I have previously researched the PostgreSQL database
cluster file that contains user data.
The result has been updated to the WIKI p
Hello.
On Tue, Oct 8, 2019 at 8:52 PM Antonin Houska wrote:
>
> Robert Haas wrote:
>
> > On Mon, Oct 7, 2019 at 3:01 PM Antonin Houska wrote:
> > > However the design doesn't seem to be stable enough at the
> > > moment for coding to make sense.
> >
> > Well, I think the question is whether wor
On Tue, Oct 8, 2019 at 7:52 AM Antonin Houska wrote:
> * Temporary files (buffile.c): we derive the IV from PID of the process that
> created the file + segment number + block within the segment. This
> information does not change if you need to write the same block again. If
> new IV should
Greetings,
* Magnus Hagander (mag...@hagander.net) wrote:
> Unless we are *absolutely* certain, I bet someone will be able to find a
> side-channel that somehow leaks some data or data-about-data, if we don't
> encrypt everything. If nothing else, you can get use patterns out of it,
> and you can
Robert Haas wrote:
> On Mon, Oct 7, 2019 at 3:01 PM Antonin Houska wrote:
> > However the design doesn't seem to be stable enough at the
> > moment for coding to make sense.
>
> Well, I think the question is whether working further on your patch
> could produce some things that everyone would a
Ants Aasma wrote:
> On Mon, 7 Oct 2019 at 18:02, Bruce Momjian wrote:
>
>> Well, do to encryption properly, there is the requirement of the nonce.
>> If you ever rewrite a bit, you technically have to have a new nonce.
>> For WAL, since it is append-only, you can use the WAL file name. Fo
On Mon, 7 Oct 2019 at 18:02, Bruce Momjian wrote:
> Well, do to encryption properly, there is the requirement of the nonce.
> If you ever rewrite a bit, you technically have to have a new nonce.
> For WAL, since it is append-only, you can use the WAL file name. For
> heap/index files, we change
On Mon, Oct 7, 2019 at 09:40:22PM +0200, Tomas Vondra wrote:
> On Mon, Oct 07, 2019 at 10:22:22AM -0400, Bruce Momjian wrote:
> > > So essentially the argument is - if you have hw crypto acceleration (aka
> > > AES-NI), then the overhead of all-cluster encryption is so low it does
> > > not make s
On Mon, Oct 7, 2019 at 3:01 PM Antonin Houska wrote:
> However the design doesn't seem to be stable enough at the
> moment for coding to make sense.
Well, I think the question is whether working further on your patch
could produce some things that everyone would agree are a step
forward. If ever
On Mon, Oct 07, 2019 at 10:22:22AM -0400, Bruce Momjian wrote:
On Sat, Oct 5, 2019 at 09:13:59PM +0200, Tomas Vondra wrote:
On Fri, Oct 04, 2019 at 08:14:44PM -0400, Bruce Momjian wrote:
> On Sat, Oct 5, 2019 at 12:54:35AM +0200, Tomas Vondra wrote:
> > On Fri, Oct 04, 2019 at 06:06:10PM -0400
Robert Haas wrote:
> On Fri, Oct 4, 2019 at 5:49 PM Bruce Momjian wrote:
> > We spend a lot of time figuring out exactly how to safely encrypt WAL,
> > heap, index, and pgsql_tmp files. The idea of doing this for another
> > 20 types of files --- to find a safe nonce, to be sure a file rewrite
On Mon, Oct 7, 2019 at 5:48 PM Bruce Momjian wrote:
> On Mon, Oct 7, 2019 at 11:26:24AM -0400, Robert Haas wrote:
> > On Mon, Oct 7, 2019 at 11:02 AM Bruce Momjian wrote:
> > > For clog, it is not append-only, and bytes are rewritten (from zero to
> > > non-zero), so there would have to be a ne
On Mon, Oct 7, 2019 at 12:34 PM Bruce Momjian wrote:
> On Mon, Oct 7, 2019 at 12:30:37PM -0400, Robert Haas wrote:
> > On Mon, Oct 7, 2019 at 11:48 AM Bruce Momjian wrote:
> > > Well, I am starting with the things I _know_ need encrypting, and am
> > > then waiting for others to tell me what to
On Mon, Oct 7, 2019 at 12:30:37PM -0400, Robert Haas wrote:
> On Mon, Oct 7, 2019 at 11:48 AM Bruce Momjian wrote:
> > Well, I am starting with the things I _know_ need encrypting, and am
> > then waiting for others to tell me what to add. Cybertec has not
> > provided a list and reasons yet, t
On Mon, Oct 7, 2019 at 11:48 AM Bruce Momjian wrote:
> Well, I am starting with the things I _know_ need encrypting, and am
> then waiting for others to tell me what to add. Cybertec has not
> provided a list and reasons yet, that I have seen. This is why I
> started this public thread, so we c
On Mon, Oct 7, 2019 at 11:26:24AM -0400, Robert Haas wrote:
> On Mon, Oct 7, 2019 at 11:02 AM Bruce Momjian wrote:
> > For clog, it is not append-only, and bytes are rewritten (from zero to
> > non-zero), so there would have to be a new nonce for every clog file
> > write to the file system. We
On Mon, Oct 7, 2019 at 11:02 AM Bruce Momjian wrote:
> For clog, it is not append-only, and bytes are rewritten (from zero to
> non-zero), so there would have to be a new nonce for every clog file
> write to the file system. We can store the nonce in a separate file,
> but the clog contents and n
On Mon, Oct 7, 2019 at 09:44:30AM -0400, Robert Haas wrote:
> On Fri, Oct 4, 2019 at 5:49 PM Bruce Momjian wrote:
> > We spend a lot of time figuring out exactly how to safely encrypt WAL,
> > heap, index, and pgsql_tmp files. The idea of doing this for another
> > 20 types of files --- to find
On Sat, Oct 5, 2019 at 09:13:59PM +0200, Tomas Vondra wrote:
> On Fri, Oct 04, 2019 at 08:14:44PM -0400, Bruce Momjian wrote:
> > On Sat, Oct 5, 2019 at 12:54:35AM +0200, Tomas Vondra wrote:
> > > On Fri, Oct 04, 2019 at 06:06:10PM -0400, Bruce Momjian wrote:
> > > > For full-cluster TDE with AES
On Fri, Oct 4, 2019 at 5:49 PM Bruce Momjian wrote:
> We spend a lot of time figuring out exactly how to safely encrypt WAL,
> heap, index, and pgsql_tmp files. The idea of doing this for another
> 20 types of files --- to find a safe nonce, to be sure a file rewrite
> doesn't reuse the nonce, f
On Fri, Oct 04, 2019 at 08:14:44PM -0400, Bruce Momjian wrote:
On Sat, Oct 5, 2019 at 12:54:35AM +0200, Tomas Vondra wrote:
On Fri, Oct 04, 2019 at 06:06:10PM -0400, Bruce Momjian wrote:
> For full-cluster TDE with AES-NI-enabled, the performance impact is
> usually ~4%, so doing anything more
On Sat, Oct 5, 2019 at 12:54:35AM +0200, Tomas Vondra wrote:
> On Fri, Oct 04, 2019 at 06:06:10PM -0400, Bruce Momjian wrote:
> > For full-cluster TDE with AES-NI-enabled, the performance impact is
> > usually ~4%, so doing anything more granular doesn't seem useful. See
> > this PGCon presentati
On Fri, Oct 04, 2019 at 06:06:10PM -0400, Bruce Momjian wrote:
On Fri, Oct 4, 2019 at 11:48:19PM +0200, Tomas Vondra wrote:
On Fri, Oct 04, 2019 at 04:58:14PM -0400, Bruce Momjian wrote:
> On Fri, Oct 4, 2019 at 10:46:57PM +0200, Tomas Vondra wrote:
> > Oracle also has a handy "TDE best practi
On Fri, Oct 4, 2019 at 11:48:19PM +0200, Tomas Vondra wrote:
> On Fri, Oct 04, 2019 at 04:58:14PM -0400, Bruce Momjian wrote:
> > On Fri, Oct 4, 2019 at 10:46:57PM +0200, Tomas Vondra wrote:
> > > Oracle also has a handy "TDE best practices" document [2], which says
> > > when to use column-level
On Fri, Oct 4, 2019 at 11:31:00PM +0200, Tomas Vondra wrote:
> On Fri, Oct 04, 2019 at 03:57:32PM -0400, Bruce Momjian wrote:
> > The current approach is to encrypt anything that contains user data,
> > which includes heap, index, and WAL files. I think replication slots
> > and logical replicati
On Fri, Oct 04, 2019 at 04:58:14PM -0400, Bruce Momjian wrote:
On Fri, Oct 4, 2019 at 10:46:57PM +0200, Tomas Vondra wrote:
Oracle also has a handy "TDE best practices" document [2], which says
when to use column-level encryption - let me quote a couple of points:
* Location of sensitive infor
On Fri, Oct 04, 2019 at 03:57:32PM -0400, Bruce Momjian wrote:
On Fri, Oct 4, 2019 at 09:18:58AM -0400, Robert Haas wrote:
I think everyone would agree that if you have no information about a
database other than the contents of pg_clog, that's not a meaningful
information leak. You would be abl
On Fri, Oct 4, 2019 at 10:46:57PM +0200, Tomas Vondra wrote:
> Oracle also has a handy "TDE best practices" document [2], which says
> when to use column-level encryption - let me quote a couple of points:
>
> * Location of sensitive information is known
>
> * Less than 5% of all application col
On Thu, Oct 03, 2019 at 01:26:55PM -0400, Stephen Frost wrote:
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
On Thu, Oct 03, 2019 at 11:51:41AM -0400, Stephen Frost wrote:
>* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
>>On Thu, Oct 03, 2019 at 10:40:40AM -0400, Stephen
On Fri, Oct 04, 2019 at 07:52:48AM +0200, Magnus Hagander wrote:
On Fri, Oct 4, 2019 at 3:42 AM Stephen Frost wrote:
> It doesn't seem like it would require
> much work at all to construct an argument that a hacker might enjoy
> having unfettered access to pg_clog even if no other part of the
On Fri, Oct 4, 2019 at 09:18:58AM -0400, Robert Haas wrote:
> I think everyone would agree that if you have no information about a
> database other than the contents of pg_clog, that's not a meaningful
> information leak. You would be able to tell which transactions
> committed and which transacti
On Thu, Oct 3, 2019 at 9:42 PM Stephen Frost wrote:
> > It doesn't seem like it would require
> > much work at all to construct an argument that a hacker might enjoy
> > having unfettered access to pg_clog even if no other part of the
> > database can be read.
>
> The question isn't about what hac
On Thu, Oct 3, 2019 at 4:40 PM Stephen Frost wrote:
>
> * Robert Haas (robertmh...@gmail.com) wrote:
> > On Mon, Sep 30, 2019 at 5:26 PM Bruce Momjian wrote:
> > > For full-cluster Transparent Data Encryption (TDE), the current plan is
> > > to encrypt all heap and index files, WAL, and all pgsq
On Fri, Oct 4, 2019 at 3:42 AM Stephen Frost wrote:
>
> > It doesn't seem like it would require
> > much work at all to construct an argument that a hacker might enjoy
> > having unfettered access to pg_clog even if no other part of the
> > database can be read.
>
> The question isn't about what
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Oct 3, 2019 at 1:29 PM Stephen Frost wrote:
> > I don't think I was arguing specifically about VM/FSM in particular but
> > rather about things which, for us, are cluster level. Admittedly, some
> > other database systems put more
On Thu, Oct 3, 2019 at 1:29 PM Stephen Frost wrote:
> I don't think I was arguing specifically about VM/FSM in particular but
> rather about things which, for us, are cluster level. Admittedly, some
> other database systems put more things into tablespaces or databases
> than we do (it'd sure be
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> On Thu, Oct 03, 2019 at 11:58:55AM -0400, Stephen Frost wrote:
> >* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> >>On 2019-10-03 16:40, Stephen Frost wrote:
> As others have said, that sounds wrong to me. I thi
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> On Thu, Oct 03, 2019 at 11:51:41AM -0400, Stephen Frost wrote:
> >* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> >>On Thu, Oct 03, 2019 at 10:40:40AM -0400, Stephen Frost wrote:
> >>>People who are looking for 'encrypt all t
On Thu, Oct 03, 2019 at 11:58:55AM -0400, Stephen Frost wrote:
Greetings,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
On 2019-10-03 16:40, Stephen Frost wrote:
>> As others have said, that sounds wrong to me. I think you need to
>> encrypt everything.
> That isn't what other d
On Thu, Oct 03, 2019 at 11:51:41AM -0400, Stephen Frost wrote:
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
On Thu, Oct 03, 2019 at 10:40:40AM -0400, Stephen Frost wrote:
>People who are looking for 'encrypt all the things' should and will be
>looking at filesytem-level encry
Greetings,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 2019-10-03 16:40, Stephen Frost wrote:
> >> As others have said, that sounds wrong to me. I think you need to
> >> encrypt everything.
> > That isn't what other database systems do though and isn't what people
> > actual
On 2019-10-03 16:40, Stephen Frost wrote:
>> As others have said, that sounds wrong to me. I think you need to
>> encrypt everything.
> That isn't what other database systems do though and isn't what people
> actually asking for this feature are expecting to have or deal with.
It is what some oth
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> On Thu, Oct 03, 2019 at 10:40:40AM -0400, Stephen Frost wrote:
> >People who are looking for 'encrypt all the things' should and will be
> >looking at filesytem-level encryption options. That's not what this
> >feature is about.
>
On Thu, Oct 03, 2019 at 10:40:40AM -0400, Stephen Frost wrote:
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
On Mon, Sep 30, 2019 at 5:26 PM Bruce Momjian wrote:
> For full-cluster Transparent Data Encryption (TDE), the current plan is
> to encrypt all heap and index files, WAL, and
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Sep 30, 2019 at 5:26 PM Bruce Momjian wrote:
> > For full-cluster Transparent Data Encryption (TDE), the current plan is
> > to encrypt all heap and index files, WAL, and all pgsql_tmp (work_mem
> > overflow). The plan is:
> >
> >
On Mon, Sep 30, 2019 at 5:26 PM Bruce Momjian wrote:
> For full-cluster Transparent Data Encryption (TDE), the current plan is
> to encrypt all heap and index files, WAL, and all pgsql_tmp (work_mem
> overflow). The plan is:
>
>
> https://wiki.postgresql.org/wiki/Transparent_Data_Encrypt
On Mon, Sep 30, 2019 at 05:26:33PM -0400, Bruce Momjian wrote:
> For full-cluster Transparent Data Encryption (TDE), the current plan is
> to encrypt all heap and index files, WAL, and all pgsql_tmp (work_mem
> overflow). The plan is:
>
>
> https://wiki.postgresql.org/wiki/Transparent_Data
On Tue, Oct 1, 2019 at 03:48:31PM +0200, Tomas Vondra wrote:
> IMO leaks of sensitive data into the server log (say, as part of error
> messages, slow queries, ...) are a serious issue. It's one of the main
> issues with pgcrypto-style encryption, because it's trivial to leak e.g.
> keys into the
On Tue, Oct 01, 2019 at 06:30:39PM +0900, Moon, Insung wrote:
Dear Magnus Hagander.
On Tue, Oct 1, 2019 at 5:37 PM Magnus Hagander wrote:
On Tue, Oct 1, 2019 at 9:33 AM Tels wrote:
Moin,
On 2019-09-30 23:26, Bruce Momjian wrote:
> For full-cluster Transparent Data Encryption (TDE), the
Dear Magnus Hagander.
On Tue, Oct 1, 2019 at 5:37 PM Magnus Hagander wrote:
>
>
>
> On Tue, Oct 1, 2019 at 9:33 AM Tels wrote:
>>
>> Moin,
>>
>> On 2019-09-30 23:26, Bruce Momjian wrote:
>> > For full-cluster Transparent Data Encryption (TDE), the current plan is
>> > to encrypt all heap and in
On Tue, Oct 1, 2019 at 9:33 AM Tels wrote:
> Moin,
>
> On 2019-09-30 23:26, Bruce Momjian wrote:
> > For full-cluster Transparent Data Encryption (TDE), the current plan is
> > to encrypt all heap and index files, WAL, and all pgsql_tmp (work_mem
> > overflow). The plan is:
> >
> >
> https://wik
Dear Tels.
On Tue, Oct 1, 2019 at 4:33 PM Tels wrote:
>
> Moin,
>
> On 2019-09-30 23:26, Bruce Momjian wrote:
> > For full-cluster Transparent Data Encryption (TDE), the current plan is
> > to encrypt all heap and index files, WAL, and all pgsql_tmp (work_mem
> > overflow). The plan is:
> >
> >
Moin,
On 2019-09-30 23:26, Bruce Momjian wrote:
For full-cluster Transparent Data Encryption (TDE), the current plan is
to encrypt all heap and index files, WAL, and all pgsql_tmp (work_mem
overflow). The plan is:
https://wiki.postgresql.org/wiki/Transparent_Data_Encryption#TODO_for_F
For full-cluster Transparent Data Encryption (TDE), the current plan is
to encrypt all heap and index files, WAL, and all pgsql_tmp (work_mem
overflow). The plan is:
https://wiki.postgresql.org/wiki/Transparent_Data_Encryption#TODO_for_Full-Cluster_Encryption
We don't see much value to
66 matches
Mail list logo
