Re: Internal key management system - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Internal key management system
Date
Msg-id CA+TgmoYvFQmHGtsrcb-Sv+4B2ZPDzsUW=GySPKAAArzaSf-mYw@mail.gmail.com
Whole thread Raw
In response to Re: Internal key management system  (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>)
Responses Re: Internal key management system
Re: Internal key management system
List pgsql-hackers
On Mon, Feb 3, 2020 at 10:18 PM Masahiko Sawada
<masahiko.sawada@2ndquadrant.com> wrote:
> > I'm lost. If pg_{en,de}crypt and pg_kmgr_unwrap are functions, what
> > prevent users to:
> >
> >    SELECT pg_kmgr_unwrap('xxxx');
> >
> > so as to recover the key, somehow in contradiction to "allows user to
> > encrypt and decrypt data without knowing the actual key".
>
> I might be missing your point but the above 'xxxx' is the wrapped key
> wrapped by the master key stored in PostgreSQL server. So user doesn't
> need to know the raw secret key to encrypt/decrypt the data. Even if a
> malicious user gets 'xxxx' they cannot know the actual secret key
> without the master key. pg_kmgr_wrap and pg_kmgr_unwrap are functions
> and it's possible for user to know the raw secret key by using
> pg_kmgr_unwrap(). The master key stored in PostgreSQL server never be
> revealed.

I think I have the same confusion as Fabien. Isn't it bad if somebody
just runs pg_kmgr_unwrap() and records the return value? Now they've
stolen your encryption key, it seems.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: relcache sometimes initially ignores has_generated_stored
Next
From: Andres Freund
Date:
Subject: Re: relcache sometimes initially ignores has_generated_stored