On Thu, Oct 29, 2020 at 1:22 AM Stephen Frost wrote:
> > Most importantly - I don't think the SQL key adds anything really
> > crucial that we cannot do at the SQL level with an extension. An
> > extension "pg_wrap" could provide pg_wrap() and pg_unwrap() already,
> > using a single master key
On Wed, Oct 28, 2020 at 05:16:32PM +0800, Craig Ringer wrote:
> On Wed, Oct 28, 2020 at 12:02 PM Craig Ringer
> wrote:
>
> On Wed, Oct 28, 2020 at 9:43 AM Bruce Momjian wrote:
> >
>
> I don't know much about how to hook into that stuff so if you have an
> idea, I am all
On Wed, Oct 28, 2020 at 02:29:16PM -0400, Bruce Momjian wrote:
> On Wed, Oct 28, 2020 at 12:02:46PM +0800, Craig Ringer wrote:
> > Yes, that's possible. But in that case the passphrase will be asked for by
> > openssl only when required, and we'll need to supply an openssl askpass
> > hook.
>
> W
On Wed, Oct 28, 2020 at 12:02:46PM +0800, Craig Ringer wrote:
> On Wed, Oct 28, 2020 at 9:43 AM Bruce Momjian wrote:
> I have used OpenSSL with Yubikey via pksc11. You
> can see the use of it on slide 57 and following:
>
> https://momjian.us/main/writings/crypto_hw_config.pd
Greetings,
* Craig Ringer (craig.rin...@enterprisedb.com) wrote:
> On Mon, Oct 26, 2020 at 11:02 PM Stephen Frost wrote:
>
> TL;DR:
>
> * Important to check that key rotation is possible on a replica, i.e.
> primary and standby can have different cluster passphrase and KEK
> encrypting the same
On Wed, Oct 28, 2020 at 09:24:35PM +0900, Masahiko Sawada wrote:
> On Tue, 27 Oct 2020 at 20:34, Bruce Momjian wrote:
> > You need to use separate keys for heap/index and WAL so you can
> > replicate to another server that uses a different heap/index key, but
> > the same WAL. You can then fail-o
On Tue, 27 Oct 2020 at 20:34, Bruce Momjian wrote:
>
> On Tue, Oct 27, 2020 at 03:07:22PM +0800, Craig Ringer wrote:
> > On Mon, Oct 26, 2020 at 11:02 PM Stephen Frost wrote:
> >
> >
> > TL;DR:
> >
> > * Important to check that key rotation is possible on a replica, i.e.
> > primary and standby c
On Wed, Oct 28, 2020 at 12:02 PM Craig Ringer
wrote:
> On Wed, Oct 28, 2020 at 9:43 AM Bruce Momjian wrote:
> >
>
>> I don't know much about how to hook into that stuff so if you have an
>> idea, I am all ears.
>
>
> Yeah, I have a reasonable idea. The main thing will be to re-read the
> patch a
On Wed, Oct 28, 2020 at 9:43 AM Bruce Momjian wrote:
>
> I don't know much about how to hook into that stuff so if you have an
> idea, I am all ears.
Yeah, I have a reasonable idea. The main thing will be to re-read the patch
and put it into more concrete terms, which I'll try to find time for
On Tue, Oct 27, 2020 at 10:20:35AM -0400, Bruce Momjian wrote:
> I don't know much about how to hook into that stuff so if you have an
> idea, I am all ears. I have used OpenSSL with Yubikey via pksc11. You
> can see the use of it on slide 57 and following:
>
> https://momjian.us/main/writ
On Tue, Oct 27, 2020 at 10:02:53PM +0800, Craig Ringer wrote:
> On Tue, 27 Oct 2020, 19:15 Bruce Momjian, wrote:
> We don't need to do anything except provide a way to tell OpenSSL where to get
> the KEK from, for situations where having Pg generate it internally
> undesirable.
>
> I proposed a
On Tue, 27 Oct 2020, 19:15 Bruce Momjian, wrote:
> We could implement a 'command:' prefix now, and maybe
> a 'pass:' one, and allow other methods like 'pkcs11' later.
>
We don't need to do anything except provide a way to tell OpenSSL where to
get the KEK from, for situations where having Pg gen
On Tue, Oct 27, 2020 at 03:07:22PM +0800, Craig Ringer wrote:
> On Mon, Oct 26, 2020 at 11:02 PM Stephen Frost wrote:
>
>
> TL;DR:
>
> * Important to check that key rotation is possible on a replica, i.e.
> primary and standby can have different cluster passphrase and KEK
> encrypting the same
On Mon, Oct 26, 2020 at 10:05:10PM +0800, Craig Ringer wrote:
> For example if I want to lock my database with a YubiHSM I would configure
> something like:
>
> cluster_encryption_key = 'pkcs11:token=YubiHSM;id=0:0001;type=private'
Well, openssl uses a prefix before the password string, e.g.:
On Mon, Oct 26, 2020 at 11:02 PM Stephen Frost wrote:
TL;DR:
* Important to check that key rotation is possible on a replica, i.e.
primary and standby can have different cluster passphrase and KEK
encrypting the same WAL and heap keys;
* with a HSM we can't read the key out, so a pluggable KEK
Greetings,
* Craig Ringer (craig.rin...@enterprisedb.com) wrote:
> On Mon, Oct 19, 2020 at 11:16 AM Masahiko Sawada
> wrote:
> > The patch introduces only key management infrastructure but with no
> > key. Currently, there is no interface to dynamically add a new
> > encryption key.
>
> I'm a b
On Mon, Oct 19, 2020 at 11:16 AM Masahiko Sawada <
masahiko.saw...@2ndquadrant.com> wrote:
The patch introduces only key management infrastructure but with no
> key. Currently, there is no interface to dynamically add a new
> encryption key.
I'm a bit confused by the exact intent and use cases b
On Sat, 17 Oct 2020 at 05:24, Bruce Momjian wrote:
>
> On Fri, Jul 31, 2020 at 04:06:38PM +0900, Masahiko Sawada wrote:
> > > Given that the purpose of the key manager is to help TDE, discussing
> > > the SQL interface part (i.g., the second patch) deviates from the
> > > original purpose. I think
On Fri, Oct 16, 2020 at 04:56:47PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Second, in testing starting/stopping the server, pg_ctl doesn't allow
> > the cluster_passphrase_command to read from /dev/tty, which I think is a
> > requirement because the command could likely require a user-s
Bruce Momjian writes:
> Second, in testing starting/stopping the server, pg_ctl doesn't allow
> the cluster_passphrase_command to read from /dev/tty, which I think is a
> requirement because the command could likely require a user-supplied
> unlock key, even if that is not the actual passphrase, j
On Fri, Jul 31, 2020 at 04:06:38PM +0900, Masahiko Sawada wrote:
> > Given that the purpose of the key manager is to help TDE, discussing
> > the SQL interface part (i.g., the second patch) deviates from the
> > original purpose. I think we should discuss the design and
> > implementation of the ke
On Fri, Jul 31, 2020 at 04:06:38PM +0900, Masahiko Sawada wrote:
> Since the previous patch sets conflicts with the current HEAD, I've
> attached the rebased patch set.
Patch 0002 fails to apply, so a rebase is needed.
--
Michael
signature.asc
Description: PGP signature
On Tue, 23 Jun 2020 at 22:46, Masahiko Sawada
wrote:
>
> On Fri, 19 Jun 2020 at 15:44, Fabien COELHO wrote:
> >
> >
> > Hello Masahiko-san,
> >
> > > What I referred to "only one key" is KEK.
> >
> > Ok, sorry, I misunderstood.
> >
> > >>> Yeah, it depends on KMS, meaning we need different extens
On Fri, 19 Jun 2020 at 15:44, Fabien COELHO wrote:
>
>
> Hello Masahiko-san,
>
> > What I referred to "only one key" is KEK.
>
> Ok, sorry, I misunderstood.
>
> >>> Yeah, it depends on KMS, meaning we need different extensions for
> >>> different KMS. A KMS might support an interface that creates
Hello Masahiko-san,
What I referred to "only one key" is KEK.
Ok, sorry, I misunderstood.
Yeah, it depends on KMS, meaning we need different extensions for
different KMS. A KMS might support an interface that creates key if not
exist during GET but some KMS might support CREATE and GET sepa
On 18/6/20 19:41, Cary Huang wrote:
Hi all
Having read through the discussion, I have some comments and
suggestions that I would like to share.
I think it is still quite early to even talk about external key
management system even if it is running on the same host as PG. This
is most likely
Hi all
Having read through the discussion, I have some comments and suggestions that I
would like to share.
I think it is still quite early to even talk about external key management
system even if it is running on the same host as PG. This is most likely
achieved as an extension that can
On Sun, 14 Jun 2020 at 19:39, Fabien COELHO wrote:
>
>
> Hello Masahiko-san,
>
> >>> * The external place needs to manage more encryption keys than the
> >>> current patch does.
> >>
> >> Why? If the external place is just a separate process on the same host,
> >> probably it would manage the very
Hello Masahiko-san,
* The external place needs to manage more encryption keys than the
current patch does.
Why? If the external place is just a separate process on the same host,
probably it would manage the very same amount as what your patch.
In the current patch, the external place need
On Sat, 13 Jun 2020 at 05:59, Fabien COELHO wrote:
>
>
> Hello Masahiko-san,
>
> > Summarizing the discussed points so far, I think that the major
> > advantage points of your idea comparing to the current patch's
> > architecture are:
> >
> > * More secure. Because it never loads KEK in postgres
Hello Bruce.
The question is what should be put in the protocol, and I would tend to
think that some careful design time should be put in it.
I still don't see the value of this vs. its complexity.
Dunno. I'm looking for the value of having such a thing in core.
ISTM that there are no cle
Hello Masahiko-san,
Summarizing the discussed points so far, I think that the major
advantage points of your idea comparing to the current patch's
architecture are:
* More secure. Because it never loads KEK in postgres processes we can
lower the likelihood of KEK leakage.
Yes.
* More exten
On Fri, Jun 12, 2020 at 09:17:37AM +0200, Fabien COELHO wrote:
> The question is what should be put in the protocol, and I would tend to
> think that some careful design time should be put in it.
I still don't see the value of this vs. its complexity.
--
Bruce Momjian https://momjian.
On Fri, 12 Jun 2020 at 16:17, Fabien COELHO wrote:
>
>
> Hello Masahiko-san,
>
> I'm not sure I understood your concern. I try to answer below.
>
> > If I understand your idea correctly we put both DEK and KEK
> > "elsewhere", and a postgres process gets only DEK from it.
>
> Yes, that is one of t
Hello Masahiko-san,
I'm not sure I understood your concern. I try to answer below.
If I understand your idea correctly we put both DEK and KEK
"elsewhere", and a postgres process gets only DEK from it.
Yes, that is one of the option.
It seems to me this idea assumes that the place storing
On Thu, 11 Jun 2020 at 20:03, Fabien COELHO wrote:
>
>
> Hello Masahiko-san,
>
> >> If the KEK is ever present in pg process, it presumes that the threat
> >> model being addressed allows its loss if the process is compromised, i.e.
> >> all (past, present, future) security properties are void onc
Hello Masahiko-san,
If the KEK is ever present in pg process, it presumes that the threat
model being addressed allows its loss if the process is compromised, i.e.
all (past, present, future) security properties are void once the process
is compromised.
Why we should not put KEK in pg proces
On Thu, 11 Jun 2020 at 16:07, Fabien COELHO wrote:
>
>
> Hello Bruce,
>
> Sorry for the length (yet again) of this answer, I'm trying to make my
> point as clear as possible.
Thank you for your explanation!
>
> >> Obviously it requires some more thinking and design, but my point is that
> >> pos
Hello Bruce,
Sorry for the length (yet again) of this answer, I'm trying to make my
point as clear as possible.
Obviously it requires some more thinking and design, but my point is that
postgres should not hold a KEK, ever, nor presume how DEK are to be managed
by a DMS, and that is not ver
On Fri, Jun 5, 2020 at 03:34:54PM +0200, Fabien COELHO wrote:
> Obviously it requires some more thinking and design, but my point is that
> postgres should not hold a KEK, ever, nor presume how DEK are to be managed
> by a DMS, and that is not very difficult to achieve by putting it outside of
> p
Hello Bruce,
Hmmm. This seels to suggest that interacting with something outside
should be an option.
Our goal is not to implement every possible security idea someone has,
because we will never finish, and the final result would be too complex
to be unable.
Sure. I'm trying to propose some
On Wed, Jun 3, 2020 at 09:16:03AM +0200, Fabien COELHO wrote:
> > > Also, I'm not at fully at ease with some of the underlying principles
> > > behind this proposal. Are we re-inventing/re-implementing kerberos or
> > > whatever? Are we re-implementing a brand new KMS inside pg? Why having
> > > o
On Wed, 3 Jun 2020 at 16:16, Fabien COELHO wrote:
>
>
> Hello Masahiko-san,
>
> > This key manager is aimed to manage cryptographic keys used for
> > transparent data encryption. As a result of the discussion, we
> > concluded it's safer to use multiple keys to encrypt database data
> > rather tha
Hello Masahiko-san,
This key manager is aimed to manage cryptographic keys used for
transparent data encryption. As a result of the discussion, we
concluded it's safer to use multiple keys to encrypt database data
rather than using one key to encrypt the whole thing, for example, in
order to ma
On Wed, 3 Jun 2020 at 08:30, Cary Huang wrote:
>
> Hi
>
>
>
> I took a step back today and started to think about the purpose of internal
> KMS and what it is supposed to do, and how it compares to external KMS. Both
> are intended to manage the life cycle of encryptions keys including their
>
Hi
I took a step back
today and started to think about the purpose of internal KMS and what it is
supposed to do, and how it compares to external KMS. Both are intended to
manage the life cycle of encryptions keys including their generation,
protection, storage and rotation. External KMS, on th
On Sat, 30 May 2020 at 04:20, Robert Haas wrote:
>
> On Fri, May 29, 2020 at 1:50 AM Masahiko Sawada
> wrote:
> > However, this usage has a downside that user secret can be logged to
> > server logs when log_statement = 'all' or an error happens. To deal
> > with this issue I've created a PoC pat
On Sun, 31 May 2020 at 17:13, Fabien COELHO wrote:
>
>
> Hello Masahiko-san,
>
> >> I am sharing here a document patch based on top of kms_v10 that was
> >> shared awhile back. This document patch aims to cover more design
> >> details of the current KMS design and to help people understand KMS
>
Hello Masahiko-san,
I am sharing here a document patch based on top of kms_v10 that was
shared awhile back. This document patch aims to cover more design
details of the current KMS design and to help people understand KMS
better. Please let me know if you have any more comments.
A few quest
On Fri, May 29, 2020 at 1:50 AM Masahiko Sawada
wrote:
> However, this usage has a downside that user secret can be logged to
> server logs when log_statement = 'all' or an error happens. To deal
> with this issue I've created a PoC patch on top of the key manager
> patch which adds a libpq functi
Hi all
I am sharing here a document patch based on top of kms_v10 that was shared
awhile back. This document patch aims to cover more design details of the
current KMS design and to help people understand KMS better. Please let me know
if you have any more comments.
thank you
Best regar
Hi Bruce/Joe,
In the last meeting we discussed the need for improving the documentation
for KMS so it is easier to understand the interface. Cary from highgo had a
go at doing that, please see the previous email on this thread from Cary
and let us know if it looks good...?
-- Ahsan
On Wed, Apr 8
Hello
Thanks a lot for the patch, I think in terms of functionality, the patch
provides very straightforward functionalities regarding key management. In
terms of documentation, I think the patch is still lacking some pieces of
information that kind of prevent people from fully understanding
On Tue, 31 Mar 2020 at 09:36, Cary Huang wrote:
>
> Hi
> I had a look on kms_v9 patch and have some comments
>
> --> pg_upgrade.c
> keys are copied correctly, but as pg_upgrade progresses further, it will try
> to start the new_cluster from "issue_warnings_and_set_wal_level()" function,
> which
Hi
I had a look on kms_v9 patch and have some comments
--> pg_upgrade.c
keys are copied correctly, but as pg_upgrade progresses further, it will try to
start the new_cluster from "issue_warnings_and_set_wal_level()" function, which
is called after key copy. The new cluster will fail to start
On Wed, Mar 25, 2020 at 05:51:08PM +0900, Masahiko Sawada wrote:
> On Tue, 24 Mar 2020 at 23:15, Bruce Momjian wrote:
> >
> > On Tue, Mar 24, 2020 at 02:29:57PM +0900, Masahiko Sawada wrote:
> > > That seems to work fine.
> > >
> > > So we will have pg_cryptokeys within PGDATA and each key is stor
On Tue, 24 Mar 2020 at 23:15, Bruce Momjian wrote:
>
> On Tue, Mar 24, 2020 at 02:29:57PM +0900, Masahiko Sawada wrote:
> > That seems to work fine.
> >
> > So we will have pg_cryptokeys within PGDATA and each key is stored
> > into separate file named the key id such as "sql", "tde-wal" and
> > "
On Tue, Mar 24, 2020 at 02:29:57PM +0900, Masahiko Sawada wrote:
> That seems to work fine.
>
> So we will have pg_cryptokeys within PGDATA and each key is stored
> into separate file named the key id such as "sql", "tde-wal" and
> "tde-block". I'll update the patch and post.
Yes, that makes sens
On Tue, 24 Mar 2020 at 07:15, Bruce Momjian wrote:
>
> On Mon, Mar 23, 2020 at 03:55:34PM +0900, Masahiko Sawada wrote:
> > On Sat, 21 Mar 2020 at 23:50, Bruce Momjian wrote:
> > > Actually, I think we need three files:
> > >
> > > * TDE WAL key file
> > > * TDE block key file
> > > * SQL-leve
On Mon, Mar 23, 2020 at 03:55:34PM +0900, Masahiko Sawada wrote:
> On Sat, 21 Mar 2020 at 23:50, Bruce Momjian wrote:
> > Actually, I think we need three files:
> >
> > * TDE WAL key file
> > * TDE block key file
> > * SQL-level file
> >
> > Primaries and standbys have to use the same TDE WAL k
On Sat, 21 Mar 2020 at 23:50, Bruce Momjian wrote:
>
> On Sat, Mar 21, 2020 at 10:01:02AM -0400, Bruce Momjian wrote:
> > On Sat, Mar 21, 2020 at 02:12:46PM +0900, Masahiko Sawada wrote:
> > > On Sat, 21 Mar 2020 at 05:30, Bruce Momjian wrote:
> > > > We should create an SQL-level master key that
On Sat, Mar 21, 2020 at 10:01:02AM -0400, Bruce Momjian wrote:
> On Sat, Mar 21, 2020 at 02:12:46PM +0900, Masahiko Sawada wrote:
> > On Sat, 21 Mar 2020 at 05:30, Bruce Momjian wrote:
> > > We should create an SQL-level master key that is different from the
> > > block-level master key. By using
On Sat, Mar 21, 2020 at 02:12:46PM +0900, Masahiko Sawada wrote:
> On Sat, 21 Mar 2020 at 05:30, Bruce Momjian wrote:
> > We should create an SQL-level master key that is different from the
> > block-level master key. By using separate keys, and not deriving them
> > from a single key, they keys
On Sat, 21 Mar 2020 at 05:30, Bruce Momjian wrote:
>
> On Thu, Mar 19, 2020 at 09:33:09PM +0900, Masahiko Sawada wrote:
> > Attached updated version patch. This patch incorporated the comments
> > and changed pg_upgrade so that we take over the master encryption key
> > from the old cluster to the
On Thu, Mar 19, 2020 at 09:33:09PM +0900, Masahiko Sawada wrote:
> Attached updated version patch. This patch incorporated the comments
> and changed pg_upgrade so that we take over the master encryption key
> from the old cluster to the new one if both enable key management.
We had a crypto team
On Fri, 20 Mar 2020 at 01:38, Bruce Momjian wrote:
>
> On Fri, Mar 20, 2020 at 12:50:27AM +0900, Masahiko Sawada wrote:
> > On Fri, Mar 20, 2020 at 0:35 Bruce Momjian wrote:
> > Well, the issue is if the user can control the user key, there is might
> > be
> > a way to make the user key
On Fri, Mar 20, 2020 at 12:50:27AM +0900, Masahiko Sawada wrote:
> On Fri, Mar 20, 2020 at 0:35 Bruce Momjian wrote:
> Well, the issue is if the user can control the user key, there is might be
> a way to make the user key do nothing.
>
> Well I meant ‘USER_KEY:’ is a fixed length string
On Fri, Mar 20, 2020 at 0:35 Bruce Momjian wrote:
> On Thu, Mar 19, 2020 at 11:42:36PM +0900, Masahiko Sawada wrote:
> > On Thu, 19 Mar 2020 at 22:00, Bruce Momjian wrote:
> > >
> > > On Thu, Mar 19, 2020 at 06:32:57PM +0900, Masahiko Sawada wrote:
> > > > On Thu, 19 Mar 2020 at 15:59, Masahiko
On Thu, Mar 19, 2020 at 11:42:36PM +0900, Masahiko Sawada wrote:
> On Thu, 19 Mar 2020 at 22:00, Bruce Momjian wrote:
> >
> > On Thu, Mar 19, 2020 at 06:32:57PM +0900, Masahiko Sawada wrote:
> > > On Thu, 19 Mar 2020 at 15:59, Masahiko Sawada
> > > > I understand that your idea is to include fixed
On Thu, 19 Mar 2020 at 22:00, Bruce Momjian wrote:
>
> On Thu, Mar 19, 2020 at 06:32:57PM +0900, Masahiko Sawada wrote:
> > On Thu, 19 Mar 2020 at 15:59, Masahiko Sawada
> > > I understand that your idea is to include fixed length string to the
> > > 256 bit key in order to separate key space. But
On Thu, Mar 19, 2020 at 06:32:57PM +0900, Masahiko Sawada wrote:
> On Thu, 19 Mar 2020 at 15:59, Masahiko Sawada
> > I understand that your idea is to include fixed length string to the
> > 256 bit key in order to separate key space. But if we do that, I think
> > that the key strength would actual
On Thu, 19 Mar 2020 at 18:32, Masahiko Sawada
wrote:
>
> On Thu, 19 Mar 2020 at 15:59, Masahiko Sawada
> wrote:
> >
> > Sending to pgsql-hackers again.
> >
> > On Tue, 17 Mar 2020 at 03:18, Bruce Momjian
> > wrote:
> > >
> > > On Mon, Mar 16, 2020 at 04:13:21PM +0900, Masahiko Sawada wrote:
> >
On Thu, 19 Mar 2020 at 15:59, Masahiko Sawada
wrote:
>
> Sending to pgsql-hackers again.
>
> On Tue, 17 Mar 2020 at 03:18, Bruce Momjian
> wrote:
> >
> > On Mon, Mar 16, 2020 at 04:13:21PM +0900, Masahiko Sawada wrote:
> > > On Thu, 12 Mar 2020 at 08:13, Bruce Momjian
> > > wrote:
> > > >
> > >
Sending to pgsql-hackers again.
On Tue, 17 Mar 2020 at 03:18, Bruce Momjian
wrote:
>
> On Mon, Mar 16, 2020 at 04:13:21PM +0900, Masahiko Sawada wrote:
> > On Thu, 12 Mar 2020 at 08:13, Bruce Momjian
> > wrote:
> > >
> > > On Fri, Mar 6, 2020 at 03:31:00PM +0900, Masahiko Sawada wrote:
> > > >
On Mon, Mar 16, 2020 at 04:13:21PM +0900, Masahiko Sawada wrote:
> On Thu, 12 Mar 2020 at 08:13, Bruce Momjian
> wrote:
> >
> > On Fri, Mar 6, 2020 at 03:31:00PM +0900, Masahiko Sawada wrote:
> > > On Fri, 6 Mar 2020 at 15:25, Moon, Insung
> > > wrote:
> > > >
> > > > Dear Sawada-san
> > > >
>
On Thu, 12 Mar 2020 at 08:13, Bruce Momjian
wrote:
>
> On Fri, Mar 6, 2020 at 03:31:00PM +0900, Masahiko Sawada wrote:
> > On Fri, 6 Mar 2020 at 15:25, Moon, Insung
> > wrote:
> > >
> > > Dear Sawada-san
> > >
> > > I don't know if my environment or email system is weird, but the V5
> > > patch
On Fri, Mar 6, 2020 at 03:31:00PM +0900, Masahiko Sawada wrote:
> On Fri, 6 Mar 2020 at 15:25, Moon, Insung wrote:
> >
> > Dear Sawada-san
> >
> > I don't know if my environment or email system is weird, but the V5
> > patch file is only include simply a changed list.
> > and previous V4 patch fi
On Fri, 6 Mar 2020 at 15:25, Moon, Insung wrote:
>
> Dear Sawada-san
>
> I don't know if my environment or email system is weird, but the V5
> patch file is only include simply a changed list.
> and previous V4 patch file size was 64kb, but the v5 patch file size was 2kb.
> Can you check it?
>
Th
Dear Sawada-san
I don't know if my environment or email system is weird, but the V5
patch file is only include simply a changed list.
and previous V4 patch file size was 64kb, but the v5 patch file size was 2kb.
Can you check it?
Best regards.
Moon.
On Tue, Mar 3, 2020 at 5:58 PM Masahiko Sawada
On Tue, 3 Mar 2020 at 08:49, Cary Huang wrote:
>
> Hi Masahiko
> Please see below my comments regarding kms_v4.patch that you have shared
> earlier.
Thank you for reviewing this patch!
>
> (1)
> There is a discrepancy between the documentation and the actual function
> definition. For example
Hi Masahiko
Please see below my comments regarding kms_v4.patch that you have shared
earlier.
(1)
There is a discrepancy between the documentation and the actual function
definition. For example in func.sgml, it states pg_wrap_key takes argument in
text data type but in pg_proc.dat and kmgr.c,
Hi
I would like to share with you a front end patch based on kms_v4.patch that you
have shared, called "kms_v4_fe.patch".
The patch integrates front end tool pg_waldump with the KMSv4 and obtain
encryption and decryption cipher contexts from the KMS backend. These cipher
contexts can then
On Thu, 20 Feb 2020 at 16:16, Masahiko Sawada
wrote:
>
> On Wed, 19 Feb 2020 at 09:29, Cary Huang wrote:
> >
> > Hi
> >
> > I have tried the attached kms_v3 patch and have some comments:
> >
> > 1) In the comments, I think you meant hmac + iv + encrypted data instead of
> > iv + hmac + encrypted
On Wed, 19 Feb 2020 at 09:29, Cary Huang wrote:
>
> Hi
>
> I have tried the attached kms_v3 patch and have some comments:
>
> 1) In the comments, I think you meant hmac + iv + encrypted data instead of
> iv + hmac + encrypted data?
>
> ---> in kmgr_wrap_key( ):
> + /*
> +* Assemble
On Sat, 15 Feb 2020 at 01:00, Robert Haas wrote:
>
> On Thu, Feb 6, 2020 at 9:19 PM Masahiko Sawada
> wrote:
> > This feature protects data from disk thefts but cannot protect data
> > from attackers who are able to access PostgreSQL server. In this
> > design application side still is responsibl
On Tue, 11 Feb 2020 at 09:58, Andres Freund wrote:
> Isn't that basically a problem of the past by now? Partially due to
> changed laws (e.g. France, which used to be a problematic case), but
> also because it's basically futile to have import restrictions on
> cryptography by now. Just about eve
Hi
I have tried the attached kms_v3 patch and have some comments:
1) In the comments, I think you meant hmac + iv + encrypted data instead of iv
+ hmac + encrypted data?
---> in kmgr_wrap_key( ):
+ /*
+ * Assemble the wrapped key. The order of the wrapped key is iv, hmac
On Thu, Feb 6, 2020 at 9:19 PM Masahiko Sawada
wrote:
> This feature protects data from disk thefts but cannot protect data
> from attackers who are able to access PostgreSQL server. In this
> design application side still is responsible for managing the wrapped
> secret in order to protect it fro
On Thu, Feb 6, 2020 at 4:37 PM Cary Huang wrote:
> Since the user does not need to know the master secret key used to cipher the
> data, I don't think we should expose "pg_kmgr_unwrap("")" SQL function to
> the user at all.
> The wrapped key "" is stored in control data and it is possibl
On Tue, 11 Feb 2020 at 10:57, Andres Freund wrote:
>
> Hi,
>
> On 2020-02-08 12:07:57 -0500, Tom Lane wrote:
> > For the same reason, I don't think that an "internal key management"
> > feature in the core code is ever going to be acceptable. It has to
> > be an extension. (But, as long as it's
On Mon, Feb 10, 2020 at 05:57:47PM -0800, Andres Freund wrote:
> Hi,
>
> On 2020-02-08 12:07:57 -0500, Tom Lane wrote:
> > For the same reason, I don't think that an "internal key management"
> > feature in the core code is ever going to be acceptable. It has to
> > be an extension. (But, as lon
Hi,
On 2020-02-08 12:07:57 -0500, Tom Lane wrote:
> For the same reason, I don't think that an "internal key management"
> feature in the core code is ever going to be acceptable. It has to
> be an extension. (But, as long as it's an extension, whether it's
> bringing its own crypto or relying o
On Wed, 5 Feb 2020 at 22:28, Sehrope Sarkuni wrote:
>
> On Sat, Feb 1, 2020 at 7:02 PM Masahiko Sawada
> wrote:
> > On Sun, 2 Feb 2020 at 00:37, Sehrope Sarkuni wrote:
> > >
> > > On Fri, Jan 31, 2020 at 1:21 AM Masahiko Sawada
> > > wrote:
> > > > On Thu, 30 Jan 2020 at 20:36, Sehrope Sarkuni
From: Andres Freund
> Perhaps this has already been discussed (I only briefly looked): I'd
> strongly advise against having any new infrastrure depend on
> pgcrypto. Its code quality imo is well below our standards and contains
> serious red flags like very outdated copies of cryptography algorith
On Sun, 9 Feb 2020 at 01:53, Tomas Vondra wrote:
>
> On Sat, Feb 08, 2020 at 07:47:24AM -0800, Andres Freund wrote:
> >Hi,
> >
> >On February 8, 2020 7:08:26 AM PST, Tomas Vondra
> > wrote:
> >>On Sat, Feb 08, 2020 at 02:48:54PM +0900, Masahiko Sawada wrote:
> >>>On Sat, 8 Feb 2020 at 03:24, Andr
Tomas Vondra writes:
> On Sat, Feb 08, 2020 at 07:47:24AM -0800, Andres Freund wrote:
>> On February 8, 2020 7:08:26 AM PST, Tomas Vondra
>> wrote:
I don't think it's very likely we'll ever merge any openssl code into
our repository, e.g. because of licensing. But we already have AES
>
On Sat, Feb 08, 2020 at 07:47:24AM -0800, Andres Freund wrote:
Hi,
On February 8, 2020 7:08:26 AM PST, Tomas Vondra
wrote:
On Sat, Feb 08, 2020 at 02:48:54PM +0900, Masahiko Sawada wrote:
On Sat, 8 Feb 2020 at 03:24, Andres Freund wrote:
Hi,
On 2020-02-07 20:44:31 +0900, Masahiko Sawada
Hi,
On February 8, 2020 7:08:26 AM PST, Tomas Vondra
wrote:
>On Sat, Feb 08, 2020 at 02:48:54PM +0900, Masahiko Sawada wrote:
>>On Sat, 8 Feb 2020 at 03:24, Andres Freund wrote:
>>>
>>> Hi,
>>>
>>> On 2020-02-07 20:44:31 +0900, Masahiko Sawada wrote:
>>> > Yeah I'm not going to use pgcrypto fo
Hi,
I wonder if this is meant to support external KMS systems/services like
Vault (from HashiCorp) or CloudHSM (from AWS) or a hardware HSM. AFAICS
the current implementation does not allow storing keys in such external
systems, right? But it seems kinda reasonable to want to do that, when
alread
On Sat, Feb 08, 2020 at 02:48:54PM +0900, Masahiko Sawada wrote:
On Sat, 8 Feb 2020 at 03:24, Andres Freund wrote:
Hi,
On 2020-02-07 20:44:31 +0900, Masahiko Sawada wrote:
> Yeah I'm not going to use pgcrypto for transparent data encryption.
> The KMS patch includes the new basic infrastructu
1 - 100 of 111 matches
Mail list logo
