Re: Internal key management system

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Internal key management system
Дата
Msg-id CA+TgmoYvFQmHGtsrcb-Sv+4B2ZPDzsUW=GySPKAAArzaSf-mYw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Internal key management system  (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>)
Ответы Re: Internal key management system  (Cary Huang <cary.huang@highgo.ca>)
Re: Internal key management system  (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: relcache sometimes initially ignores has_generated_stored
Следующее
От: Andres Freund
Дата:
Сообщение: Re: relcache sometimes initially ignores has_generated_stored