On Tue, Jul 9, 2019 at 08:01:35AM -0400, Joe Conway wrote:
> On 7/9/19 6:07 AM, Peter Eisentraut wrote:
> > On 2019-07-08 18:09, Joe Conway wrote:
> >> In my mind, and in practice to a
> >> large extent, a postgres tablespace == a unique mount point.
> >
> > But a critical difference is that in f
On 7/9/19 8:39 AM, Ryan Lambert wrote:
> Hi Thomas,
>
>> CBC mode does require
>> random nonces, other modes may be fine with even sequences as long as
>> the values are not reused.
>
> I disagree that CBC mode requires random nonces, at least based on what
> NIST has published. They only req
Hi Thomas,
> CBC mode does require
> random nonces, other modes may be fine with even sequences as long as
> the values are not reused.
I disagree that CBC mode requires random nonces, at least based on what
NIST has published. They only require that the IV (not the nonce) must be
unpredictable
On 7/9/19 6:07 AM, Peter Eisentraut wrote:
> On 2019-07-08 18:09, Joe Conway wrote:
>> In my mind, and in practice to a
>> large extent, a postgres tablespace == a unique mount point.
>
> But a critical difference is that in file systems, a separate mount
> point has its own journal.
While it wou
On 7/9/19 4:23 AM, Tomas Vondra wrote:
> On Mon, Jul 08, 2019 at 06:24:40PM -0400, Joe Conway wrote:
>>On 7/8/19 6:04 PM, Stephen Frost wrote:
>>> * Bruce Momjian (br...@momjian.us) wrote:
Uh, well, renaming the user was a big problem, but that is the only case
I can think of. I don't se
On 7/9/19 4:34 AM, Tomas Vondra wrote:
> On Mon, Jul 08, 2019 at 06:45:50PM -0400, Bruce Momjian wrote:
>>On Mon, Jul 8, 2019 at 06:23:13PM -0400, Bruce Momjian wrote:
>>> Yes, 'postgres' can be used to create a nice md5 rainbow table that
>>> works on many servers --- good point. Are rainbow tab
On 2019-07-08 18:09, Joe Conway wrote:
> In my mind, and in practice to a
> large extent, a postgres tablespace == a unique mount point.
But a critical difference is that in file systems, a separate mount
point has its own journal.
--
Peter Eisentraut http://www.2ndQuadrant.com/
Pos
On Mon, Jul 8, 2019 at 11:20 PM Bruce Momjian wrote:
>
> On Mon, Jul 8, 2019 at 06:04:28PM +0900, Masahiko Sawada wrote:
> > On Sun, Jul 7, 2019 at 1:05 AM Bruce Momjian wrote:
> > > What about referential integrity constraints that need to check primary
> > > keys in the encrypted tables? I al
On Mon, Jul 08, 2019 at 05:41:55PM -0400, Bruce Momjian wrote:
On Mon, Jul 8, 2019 at 09:30:03PM +0200, Tomas Vondra wrote:
I think Bruce's proposal was to minimize the time the key is "unlocked"
in memory by only unlocking them when the user connects and supplies
some sort of secret (passphras
On Mon, Jul 08, 2019 at 06:45:50PM -0400, Bruce Momjian wrote:
On Mon, Jul 8, 2019 at 06:23:13PM -0400, Bruce Momjian wrote:
Yes, 'postgres' can be used to create a nice md5 rainbow table that
works on many servers --- good point. Are rainbow tables possible with
something like AES?
> I appre
On Mon, Jul 08, 2019 at 06:24:40PM -0400, Joe Conway wrote:
On 7/8/19 6:04 PM, Stephen Frost wrote:
* Bruce Momjian (br...@momjian.us) wrote:
Uh, well, renaming the user was a big problem, but that is the only case
I can think of. I don't see that as an issue for block or WAL sequence
numbers.
On Tue, Jul 9, 2019 at 3:39 AM Tomas Vondra
wrote:
>
> BTW how do you know this is what users want? Maybe they do, but then
> again - maybe they just see it as magic and don't realize the extra
> complexity (not just at the database level). In my experience users
> generally want more abstract thi
Hey everyone,
Here is my input regarding nonces and randomness.
> As I understand it, the NIST recommendation is a 96-bit *random* nonce,
I could not find that exact requirement in the NIST documents, though given
the volume of that library it would be possible to miss. The
recommendation I rep
On Mon, Jul 8, 2019 at 07:27:12PM -0400, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > Operationally, how would that work? We unlock them all on boot but
> > somehow make them inaccessible to some backends after that?
>
> That could work and doesn't seem like an insurmount
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Mon, Jul 8, 2019 at 06:43:31PM -0400, Stephen Frost wrote:
> > * Bruce Momjian (br...@momjian.us) wrote:
> > > On Mon, Jul 8, 2019 at 06:04:46PM -0400, Stephen Frost wrote:
> > > > * Bruce Momjian (br...@momjian.us) wrote:
> > > > > On Mo
On Mon, Jul 8, 2019 at 06:43:31PM -0400, Stephen Frost wrote:
> Greetings,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Mon, Jul 8, 2019 at 06:04:46PM -0400, Stephen Frost wrote:
> > > * Bruce Momjian (br...@momjian.us) wrote:
> > > > On Mon, Jul 8, 2019 at 05:41:51PM -0400, Stephen Fro
On Mon, Jul 8, 2019 at 06:23:13PM -0400, Bruce Momjian wrote:
> Yes, 'postgres' can be used to create a nice md5 rainbow table that
> works on many servers --- good point. Are rainbow tables possible with
> something like AES?
>
> > I appreciate that *some* of this might not be completely releva
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Mon, Jul 8, 2019 at 06:04:46PM -0400, Stephen Frost wrote:
> > * Bruce Momjian (br...@momjian.us) wrote:
> > > On Mon, Jul 8, 2019 at 05:41:51PM -0400, Stephen Frost wrote:
> > > > * Bruce Momjian (br...@momjian.us) wrote:
> > > > > Well,
On 7/8/19 6:04 PM, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
>> Uh, well, renaming the user was a big problem, but that is the only case
>> I can think of. I don't see that as an issue for block or WAL sequence
>> numbers. If we want to use a different nonce, we have to fin
On Mon, Jul 8, 2019 at 06:04:46PM -0400, Stephen Frost wrote:
> Greetings,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Mon, Jul 8, 2019 at 05:41:51PM -0400, Stephen Frost wrote:
> > > * Bruce Momjian (br...@momjian.us) wrote:
> > > > Well, if it was a necessary features, I assume TLS 1.
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Mon, Jul 8, 2019 at 05:41:51PM -0400, Stephen Frost wrote:
> > * Bruce Momjian (br...@momjian.us) wrote:
> > > Well, if it was a necessary features, I assume TLS 1.3 would have found
> > > a way to make it secure, no? Certainly they are n
On Mon, Jul 8, 2019 at 05:41:51PM -0400, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > Well, if it was a necessary features, I assume TLS 1.3 would have found
> > a way to make it secure, no? Certainly they are not shipping TLS 1.3
> > with a known weakness.
>
> As discuss
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Mon, Jul 8, 2019 at 02:39:44PM -0400, Stephen Frost wrote:
> > > > Of course, we can discuss if what websites do with over-the-wire
> > > > encryption is sensible to compare to what we want to do in PG for
> > > > data-at-rest, but then we
On Mon, Jul 8, 2019 at 09:30:03PM +0200, Tomas Vondra wrote:
> I think Bruce's proposal was to minimize the time the key is "unlocked"
> in memory by only unlocking them when the user connects and supplies
> some sort of secret (passphrase), and remove them from memory when the
> user disconnects.
On Mon, Jul 8, 2019 at 02:39:44PM -0400, Stephen Frost wrote:
> > > Of course, we can discuss if what websites do with over-the-wire
> > > encryption is sensible to compare to what we want to do in PG for
> > > data-at-rest, but then we shouldn't be talking about what websites do,
> > > it'd make
On Mon, Jul 8, 2019 at 12:09:58PM -0400, Joe Conway wrote:
> On 7/8/19 11:56 AM, Peter Eisentraut wrote:
> > On 2019-07-08 17:47, Stephen Frost wrote:
> >> Of course, we can discuss if what websites do with over-the-wire
> >> encryption is sensible to compare to what we want to do in PG for
> >> d
On Mon, Jul 08, 2019 at 12:09:58PM -0400, Joe Conway wrote:
On 7/8/19 11:56 AM, Peter Eisentraut wrote:
On 2019-07-08 17:47, Stephen Frost wrote:
Of course, we can discuss if what websites do with over-the-wire
encryption is sensible to compare to what we want to do in PG for
data-at-rest, but
On Mon, Jul 08, 2019 at 12:16:04PM -0400, Bruce Momjian wrote:
...
Anyway, I will to research the reasonable data size that can be secured
with a single key via AES. I will look at how PGP encrypts large files
too.
IMO there are various recommendations about this, for example from NIST.
But
On Mon, Jul 08, 2019 at 02:39:44PM -0400, Stephen Frost wrote:
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
On Mon, Jul 8, 2019 at 11:47:33AM -0400, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Mon, Jul 8, 2019 at 11:18:01AM -0400, Joe Conway wrote:
> > > On
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Mon, Jul 8, 2019 at 11:47:33AM -0400, Stephen Frost wrote:
> > * Bruce Momjian (br...@momjian.us) wrote:
> > > On Mon, Jul 8, 2019 at 11:18:01AM -0400, Joe Conway wrote:
> > > > On 7/8/19 10:19 AM, Bruce Momjian wrote:
> > > > > When peop
On Mon, Jul 08, 2019 at 11:25:10AM -0400, Bruce Momjian wrote:
On Mon, Jul 8, 2019 at 11:18:01AM -0400, Joe Conway wrote:
On 7/8/19 10:19 AM, Bruce Momjian wrote:
> When people are asking for multiple keys (not just for key rotation),
> they are asking to have multiple keys that can be supplied
On Mon, Jul 8, 2019 at 11:47:33AM -0400, Stephen Frost wrote:
> Greetings,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Mon, Jul 8, 2019 at 11:18:01AM -0400, Joe Conway wrote:
> > > On 7/8/19 10:19 AM, Bruce Momjian wrote:
> > > > When people are asking for multiple keys (not just for ke
On 7/8/19 11:56 AM, Peter Eisentraut wrote:
> On 2019-07-08 17:47, Stephen Frost wrote:
>> Of course, we can discuss if what websites do with over-the-wire
>> encryption is sensible to compare to what we want to do in PG for
>> data-at-rest, but then we shouldn't be talking about what websites do,
On 2019-07-08 17:47, Stephen Frost wrote:
> Of course, we can discuss if what websites do with over-the-wire
> encryption is sensible to compare to what we want to do in PG for
> data-at-rest, but then we shouldn't be talking about what websites do,
> it'd make more sense to look at other data-at-r
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Mon, Jul 8, 2019 at 11:18:01AM -0400, Joe Conway wrote:
> > On 7/8/19 10:19 AM, Bruce Momjian wrote:
> > > When people are asking for multiple keys (not just for key rotation),
> > > they are asking to have multiple keys that can be suppli
On Mon, Jul 8, 2019 at 11:18:01AM -0400, Joe Conway wrote:
> On 7/8/19 10:19 AM, Bruce Momjian wrote:
> > When people are asking for multiple keys (not just for key rotation),
> > they are asking to have multiple keys that can be supplied by users only
> > when they need to access the data. Yes,
On 7/8/19 10:19 AM, Bruce Momjian wrote:
> When people are asking for multiple keys (not just for key rotation),
> they are asking to have multiple keys that can be supplied by users only
> when they need to access the data. Yes, the keys are always in the
> datbase, but the feature request is tha
On Mon, Jul 8, 2019 at 06:04:28PM +0900, Masahiko Sawada wrote:
> On Sun, Jul 7, 2019 at 1:05 AM Bruce Momjian wrote:
> > What about referential integrity constraints that need to check primary
> > keys in the encrypted tables? I also don't see a way of delaying that,
> > and if you can't do ref
On Sun, Jul 7, 2019 at 1:05 AM Bruce Momjian wrote:
>
> On Fri, Jul 5, 2019 at 10:24:39PM +0200, Tomas Vondra wrote:
> > I agree this is a pretty crucial challenge, and those requirements seem
> > in direct conflict. Users use encryption to protect privacy of the data,
> > but we need access to s
On 2019-07-05 22:24, Tomas Vondra wrote:
> What if the granular encryption (not the "whole cluster with a single
> key") case does not encrypt whole blocks, but just tuple data? Would
> that allow at least the most critical WAL use cases (recovery, physical
> replication) to work without having to
On Fri, Jul 5, 2019 at 10:24:39PM +0200, Tomas Vondra wrote:
> I agree this is a pretty crucial challenge, and those requirements seem
> in direct conflict. Users use encryption to protect privacy of the data,
> but we need access to some of the data to implement some of the
> important tasks of a
On 2019-Jul-05, Bruce Momjian wrote:
> On Fri, Jul 5, 2019 at 05:00:42PM -0400, Bruce Momjian wrote:
> > On Fri, Jul 5, 2019 at 04:24:54PM -0400, Alvaro Herrera wrote:
> > > Oh, is that the idea? I was kinda assuming that the data was kept
> > > as-stored in shared buffers, ie. it would be dec
On Fri, Jul 5, 2019 at 04:10:04PM -0400, Bruce Momjian wrote:
> On Fri, Jul 5, 2019 at 03:46:28PM -0400, Alvaro Herrera wrote:
> > On 2019-Jul-05, Bruce Momjian wrote:
> >
> > > What people really want with more-granular-than-cluster encryption is
> > > the ability to supply their passphrase key
On Fri, Jul 5, 2019 at 05:00:42PM -0400, Bruce Momjian wrote:
> On Fri, Jul 5, 2019 at 04:24:54PM -0400, Alvaro Herrera wrote:
> > On 2019-Jul-05, Bruce Momjian wrote:
> >
> > > Uh, well, you have the WAL record, and you want to write it to an 8k
> > > page. You have to read the 8k page from di
On Fri, Jul 5, 2019 at 05:00:42PM -0400, Bruce Momjian wrote:
> On Fri, Jul 5, 2019 at 04:24:54PM -0400, Alvaro Herrera wrote:
> > On 2019-Jul-05, Bruce Momjian wrote:
> >
> > > Uh, well, you have the WAL record, and you want to write it to an 8k
> > > page. You have to read the 8k page from di
On Fri, Jul 5, 2019 at 04:24:54PM -0400, Alvaro Herrera wrote:
> On 2019-Jul-05, Bruce Momjian wrote:
>
> > Uh, well, you have the WAL record, and you want to write it to an 8k
> > page. You have to read the 8k page from disk into shared buffers, and
> > you have to decrypt the 8k page to do tha
On 2019-Jul-05, Bruce Momjian wrote:
> Uh, well, you have the WAL record, and you want to write it to an 8k
> page. You have to read the 8k page from disk into shared buffers, and
> you have to decrypt the 8k page to do that, right? We aren't going to
> store 8k pages encrypted in shared buffers
On Fri, Jul 05, 2019 at 03:38:28PM -0400, Bruce Momjian wrote:
On Sun, Jun 16, 2019 at 03:57:46PM -0400, Stephen Frost wrote:
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Sun, Jun 16, 2019 at 12:42:55PM -0400, Joe Conway wrote:
> > On 6/16/19 9:45 AM, Bruce Momjian wrote:
> > > On
On Fri, Jul 5, 2019 at 03:46:28PM -0400, Alvaro Herrera wrote:
> On 2019-Jul-05, Bruce Momjian wrote:
>
> > What people really want with more-granular-than-cluster encryption is
> > the ability to supply their passphrase key _when_ they want to access
> > their data, and then leave and be sure th
On 2019-Jul-05, Stephen Frost wrote:
> I had been specifically thinking of tablespaces because we might be able
> to do something exactly along these lines- keep which tablespace the
> data is in directly in the WAL (and not encrypted), but then have the
> data itself be encrypted, and with the ke
Greetings,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> On 2019-Jul-05, Bruce Momjian wrote:
>
> > What people really want with more-granular-than-cluster encryption is
> > the ability to supply their passphrase key _when_ they want to access
> > their data, and then leave and be sure the
On 2019-Jul-05, Bruce Momjian wrote:
> What people really want with more-granular-than-cluster encryption is
> the ability to supply their passphrase key _when_ they want to access
> their data, and then leave and be sure their data is secure from
> decryption. That will not be possible since the
On Sun, Jun 16, 2019 at 07:07:20AM -0400, Joe Conway wrote:
> On 6/15/19 9:28 PM, Bruce Momjian wrote:
> > There are no known non-exhaustive plaintext attacks on AES:
> >
> >
> > https://crypto.stackexchange.com/questions/1512/why-is-aes-resistant-to-known-plaintext-attacks
>
> Even that non
On Sun, Jun 16, 2019 at 03:57:46PM -0400, Stephen Frost wrote:
> Greetings,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Sun, Jun 16, 2019 at 12:42:55PM -0400, Joe Conway wrote:
> > > On 6/16/19 9:45 AM, Bruce Momjian wrote:
> > > > On Sun, Jun 16, 2019 at 07:07:20AM -0400, Joe Conway wrot
On Thu, Jun 20, 2019 at 10:46 PM Joe Conway wrote:
>
> On 6/20/19 8:34 AM, Masahiko Sawada wrote:
> > I think even if we provide the per table encryption we can have
> > encryption keys per tablepaces. That is, all tables on the same
> > tablespace encryption use the same encryption keys but user
On 6/20/19 8:34 AM, Masahiko Sawada wrote:
> I think even if we provide the per table encryption we can have
> encryption keys per tablepaces. That is, all tables on the same
> tablespace encryption use the same encryption keys but user can
> control encrypted objects per tables.
>
>> Will we add
On Tue, Jun 18, 2019 at 5:07 PM shawn wang wrote:
>
> Masahiko Sawada 于2019年6月17日周一 下午8:30写道：
>>
>> On Fri, Jun 14, 2019 at 7:41 AM Tomas Vondra
>> wrote:
>> > I personally find the idea of encrypting tablespaces rather strange.
>> > Tablespaces are meant to define hysical location for objects,
Masahiko Sawada 于2019年6月17日周一 下午8:30写道：
> On Fri, Jun 14, 2019 at 7:41 AM Tomas Vondra
> wrote:
> > I personally find the idea of encrypting tablespaces rather strange.
> > Tablespaces are meant to define hysical location for objects, but this
> > would also use them to "mark" objects as encrypt
On Mon, Jun 17, 2019 at 10:33:11AM -0400, Stephen Frost wrote:
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
In any case, if we end up with a more complex/advanced design, I've
already voiced my opinion that binding the keys to tablespaces is the
wrong abstraction, and I think
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> In any case, if we end up with a more complex/advanced design, I've
> already voiced my opinion that binding the keys to tablespaces is the
> wrong abstraction, and I think we'll regret it eventually. For example,
> why have we inve
On Mon, Jun 17, 2019 at 08:29:02AM -0400, Joe Conway wrote:
On 6/17/19 8:12 AM, Stephen Frost wrote:
But there's about 0% chance we'll get that in v1, of course, so we need
s "minimum viable product" to build on anyway.
There seems like a whole lot of space between something very elaborate
and
On Mon, Jun 17, 2019 at 08:39:27AM -0400, Joe Conway wrote:
On 6/17/19 8:29 AM, Masahiko Sawada wrote:
From perspective of cryptographic, I think the fine grained TDE would
be better solution. Therefore if we eventually want the fine grained
TDE I wonder if it might be better to develop the tab
Antonin Houska wrote:
> Masahiko Sawada wrote:
>
> > The cluster-wide TDE eventually encrypts SLRU data and all WAL
> > including non-user data related WAL while table/tablespace TDE doesn't
> > unless we develop such functionality. In addition, the cluster-wide
> > TDE also encrypts system cat
Masahiko Sawada wrote:
> The cluster-wide TDE eventually encrypts SLRU data and all WAL
> including non-user data related WAL while table/tablespace TDE doesn't
> unless we develop such functionality. In addition, the cluster-wide
> TDE also encrypts system catalogs but in table/tablespace TDE us
On 6/17/19 8:29 AM, Masahiko Sawada wrote:
> From perspective of cryptographic, I think the fine grained TDE would
> be better solution. Therefore if we eventually want the fine grained
> TDE I wonder if it might be better to develop the table/tablespace TDE
> first while keeping it simple as much
On Fri, Jun 14, 2019 at 7:41 AM Tomas Vondra
wrote:
> I personally find the idea of encrypting tablespaces rather strange.
> Tablespaces are meant to define hysical location for objects, but this
> would also use them to "mark" objects as encrypted or not. That just
> seems misguided and would mak
On 6/17/19 8:12 AM, Stephen Frost wrote:
>> But there's about 0% chance we'll get that in v1, of course, so we need
>> s "minimum viable product" to build on anyway.
>
> There seems like a whole lot of space between something very elaborate
> and only supporting one key.
I think this is exactly t
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> On Sun, Jun 16, 2019 at 02:10:23PM -0400, Stephen Frost wrote:
> >* Joe Conway (m...@joeconway.com) wrote:
> >>On 6/16/19 9:45 AM, Bruce Momjian wrote:
> >>> On Sun, Jun 16, 2019 at 07:07:20AM -0400, Joe Conway wrote:
> In any
On Sun, Jun 16, 2019 at 02:10:23PM -0400, Stephen Frost wrote:
Greetings,
* Joe Conway (m...@joeconway.com) wrote:
On 6/16/19 9:45 AM, Bruce Momjian wrote:
> On Sun, Jun 16, 2019 at 07:07:20AM -0400, Joe Conway wrote:
>> In any case it doesn't address my first point, which is limiting the
>> vo
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Sun, Jun 16, 2019 at 12:42:55PM -0400, Joe Conway wrote:
> > On 6/16/19 9:45 AM, Bruce Momjian wrote:
> > > On Sun, Jun 16, 2019 at 07:07:20AM -0400, Joe Conway wrote:
> > >> In any case it doesn't address my first point, which is limiting
On Sun, Jun 16, 2019 at 12:42:55PM -0400, Joe Conway wrote:
> On 6/16/19 9:45 AM, Bruce Momjian wrote:
> > On Sun, Jun 16, 2019 at 07:07:20AM -0400, Joe Conway wrote:
> >> In any case it doesn't address my first point, which is limiting the
> >> volume encrypted with the same key. Another valid rea
Greetings,
* Joe Conway (m...@joeconway.com) wrote:
> On 6/16/19 9:45 AM, Bruce Momjian wrote:
> > On Sun, Jun 16, 2019 at 07:07:20AM -0400, Joe Conway wrote:
> >> In any case it doesn't address my first point, which is limiting the
> >> volume encrypted with the same key. Another valid reason is
On 6/16/19 9:46 AM, Bruce Momjian wrote:
> On Sun, Jun 16, 2019 at 09:45:09AM -0400, Bruce Momjian wrote:
>> On Sun, Jun 16, 2019 at 07:07:20AM -0400, Joe Conway wrote:
>> > And although I'm not proposing this for the first implementation, yet
>> > another reason is I might want to additionally con
On 6/16/19 9:45 AM, Bruce Momjian wrote:
> On Sun, Jun 16, 2019 at 07:07:20AM -0400, Joe Conway wrote:
>> In any case it doesn't address my first point, which is limiting the
>> volume encrypted with the same key. Another valid reason is you might
>> have data at varying sensitivity levels and pref
On Sun, Jun 16, 2019 at 07:07:20AM -0400, Joe Conway wrote:
> On 6/15/19 9:28 PM, Bruce Momjian wrote:
> >> There are reasons other than performance to want more granular than
> >> entire cluster encryption. Limiting the volume of encrypted data with
> >> any one key for example. And not encrypting
On Sun, Jun 16, 2019 at 09:45:09AM -0400, Bruce Momjian wrote:
> On Sun, Jun 16, 2019 at 07:07:20AM -0400, Joe Conway wrote:
> > And although I'm not proposing this for the first implementation, yet
> > another reason is I might want to additionally control "transparent
> > access" to data based on
On 6/15/19 9:28 PM, Bruce Momjian wrote:
> On Fri, Jun 14, 2019 at 02:27:17PM -0400, Joe Conway wrote:
>> On 6/13/19 11:07 AM, Bruce Momjian wrote:
>> > On Thu, Jun 13, 2019 at 04:26:47PM +0900, Masahiko Sawada wrote:
>> >> Yeah, in principle since data key of 2 tier key architecture should
>> >> n
On Fri, Jun 14, 2019 at 02:27:17PM -0400, Joe Conway wrote:
> On 6/13/19 11:07 AM, Bruce Momjian wrote:
> > On Thu, Jun 13, 2019 at 04:26:47PM +0900, Masahiko Sawada wrote:
> >> Yeah, in principle since data key of 2 tier key architecture should
> >> not go outside database I think we should not te
On Fri, Jun 14, 2019 at 09:37:37PM -0400, Joe Conway wrote:
> On 6/14/19 6:09 PM, Bruce Momjian wrote:
> > On Fri, Jun 14, 2019 at 02:27:17PM -0400, Joe Conway wrote:
> >> On 6/13/19 11:07 AM, Bruce Momjian wrote:
> >> > In addition, while the 8k blocks would use a block cipher, the WAL would
> >>
On 6/14/19 6:09 PM, Bruce Momjian wrote:
> On Fri, Jun 14, 2019 at 02:27:17PM -0400, Joe Conway wrote:
>> On 6/13/19 11:07 AM, Bruce Momjian wrote:
>> > In addition, while the 8k blocks would use a block cipher, the WAL would
>> > likely use a stream cipher, and it will be very hard to use multiple
On Fri, Jun 14, 2019 at 02:27:17PM -0400, Joe Conway wrote:
> On 6/13/19 11:07 AM, Bruce Momjian wrote:
> > On Thu, Jun 13, 2019 at 04:26:47PM +0900, Masahiko Sawada wrote:
> >> Yeah, in principle since data key of 2 tier key architecture should
> >> not go outside database I think we should not te
On 6/13/19 11:07 AM, Bruce Momjian wrote:
> On Thu, Jun 13, 2019 at 04:26:47PM +0900, Masahiko Sawada wrote:
>> Yeah, in principle since data key of 2 tier key architecture should
>> not go outside database I think we should not tell data keys to
>> utility commands. So the rearranging WAL format s
On Fri, Jun 14, 2019 at 02:12:07AM +0200, Tomas Vondra wrote:
> FWIW my assumption was that we could just add an "encrypted" flag into
> the main XLogRecord header, and then an extra part with important
> encryption-related data - the key, and the important metadata needed by
> external tools (e.g.
On Fri, Jun 14, 2019 at 9:12 AM Tomas Vondra
wrote:
>
> On Thu, Jun 13, 2019 at 07:49:48PM -0400, Bruce Momjian wrote:
> >On Fri, Jun 14, 2019 at 12:41:17AM +0200, Tomas Vondra wrote:
> >> On Thu, Jun 13, 2019 at 11:07:25AM -0400, Bruce Momjian wrote:
> >> IMHO we should implement the simplest sys
On Thu, Jun 13, 2019 at 07:49:48PM -0400, Bruce Momjian wrote:
On Fri, Jun 14, 2019 at 12:41:17AM +0200, Tomas Vondra wrote:
On Thu, Jun 13, 2019 at 11:07:25AM -0400, Bruce Momjian wrote:
IMHO we should implement the simplest system possible, and optimize the
hell out of it without sacrificing a
On Fri, Jun 14, 2019 at 12:41:17AM +0200, Tomas Vondra wrote:
> On Thu, Jun 13, 2019 at 11:07:25AM -0400, Bruce Momjian wrote:
> IMHO we should implement the simplest system possible, and optimize the
> hell out of it without sacrificing any safety/security aspects. No smart
> tunables, no extra GU
On Thu, Jun 13, 2019 at 11:07:25AM -0400, Bruce Momjian wrote:
On Thu, Jun 13, 2019 at 04:26:47PM +0900, Masahiko Sawada wrote:
On Thu, Jun 13, 2019 at 3:48 AM Bruce Momjian wrote:
> The big question is how many people will be mixing encrypted and
> unencrypted data in the same cluster, and car
On Thu, Jun 13, 2019 at 04:26:47PM +0900, Masahiko Sawada wrote:
> On Thu, Jun 13, 2019 at 3:48 AM Bruce Momjian wrote:
> > The big question is how many people will be mixing encrypted and
> > unencrypted data in the same cluster, and care about performance? Just
> > because someone might care is
On Thu, Jun 13, 2019 at 3:48 AM Bruce Momjian wrote:
>
> On Wed, Jun 5, 2019 at 11:54:04AM +0900, Masahiko Sawada wrote:
> > On Fri, May 10, 2019 at 2:42 AM Bruce Momjian wrote:
> > > I think we need to step back and see what we want to do. There are six
> > > levels of possible encryption:
> >
On Wed, Jun 5, 2019 at 11:54:04AM +0900, Masahiko Sawada wrote:
> On Fri, May 10, 2019 at 2:42 AM Bruce Momjian wrote:
> > I think we need to step back and see what we want to do. There are six
> > levels of possible encryption:
> >
> > 1. client-side column encryption
> > 2. server-side colum
On Fri, May 10, 2019 at 2:42 AM Bruce Momjian wrote:
>
> On Thu, May 9, 2019 at 05:49:12PM +0900, Masahiko Sawada wrote:
> > In terms of keys, one advantage could be that we have less keys with
> > per-tablespace keys.
> >
> > Let me briefly explain the current design I'm thinking. The design
> >
On Mon, May 13, 2019 at 2:09 PM Smith, Peter wrote:
>
> Hi Masahiko,
>
> > Let me briefly explain the current design I'm thinking. The design
> > employees 2-tier key architecture. That is, a database cluster has one
> > master key and per-tablespace keys which are encrypted with the master key
Hi Masahiko,
> Let me briefly explain the current design I'm thinking. The design employees
> 2-tier key architecture. That is, a database cluster has one
> master key and per-tablespace keys which are encrypted with the master key
> before storing to disk. Each tablespace keys are generated
> r
On Thu, May 9, 2019 at 05:49:12PM +0900, Masahiko Sawada wrote:
> In terms of keys, one advantage could be that we have less keys with
> per-tablespace keys.
>
> Let me briefly explain the current design I'm thinking. The design
> employees 2-tier key architecture. That is, a database cluster has
On Wed, May 8, 2019 at 09:32:08AM -0400, Robert Haas wrote:
> On Tue, May 7, 2019 at 2:10 AM Masahiko Sawada wrote:
> > > > That better not be true. If you have a design where reading the WAL
> > > > lets you get *any* encryption key, you have a bad design, I think.
> >
> > How does the startup
On Wed, May 8, 2019 at 10:32 PM Robert Haas wrote:
>
> On Tue, May 7, 2019 at 2:10 AM Masahiko Sawada wrote:
> > > > That better not be true. If you have a design where reading the WAL
> > > > lets you get *any* encryption key, you have a bad design, I think.
> >
> > How does the startup process
On Tue, May 7, 2019 at 2:10 AM Masahiko Sawada wrote:
> > > That better not be true. If you have a design where reading the WAL
> > > lets you get *any* encryption key, you have a bad design, I think.
>
> How does the startup process decrypt WAL during recovery without
> getting any encryption ke
On Wed, May 1, 2019 at 9:30 AM Robert Haas wrote:
>
> Replying to myself to resend to the list, since my previous attempt
> seems to have been eaten by a grue.
>
> On Tue, Apr 30, 2019 at 1:01 PM Robert Haas wrote:
> >
> > On Tue, Apr 30, 2019 at 1:38 AM Masahiko Sawada
> > wrote:
> > > It seem
Replying to myself to resend to the list, since my previous attempt
seems to have been eaten by a grue.
On Tue, Apr 30, 2019 at 1:01 PM Robert Haas wrote:
>
> On Tue, Apr 30, 2019 at 1:38 AM Masahiko Sawada wrote:
> > It seems to me that encrypting table data in WAL with multiple keys
> > reduce
On Thu, Mar 14, 2019 at 8:30 AM Masahiko Sawada wrote:
> So I think there is no such insider thread problem, right?
No, I think that's a really bad assumption. If there's no insider
threat, then what exactly ARE you guarding against? If somebody
steals the disk, you don't need PostgreSQL to do
301 - 400 of 483 matches
Mail list logo
