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

From Fabien COELHO
Subject Re: Internal key management system
Date
Msg-id alpine.DEB.2.21.2002020854150.20752@pseudo
Whole thread Raw
In response to Internal key management system  (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>)
Responses Re: Internal key management system
List pgsql-hackers
Hello Masahiko-san,

> I've started a new separate thread from the previous long thread[1]
> for internal key management system to PostgreSQL. As I mentioned in
> the previous mail[2], we've decided to step back and focus on only
> internal key management system for PG13. The internal key management
> system introduces the functionality to PostgreSQL that allows user to
> encrypt and decrypt data without knowing the actual key. Besides, it
> will be able to be integrated with transparent data encryption in the
> future.
>
> The basic idea is that PostgreSQL generates the master encryption key
> which is further protected by the user-provided passphrase. The key
> management system provides two functions to wrap and unwrap the secret
> by the master encryption key. A user generates a secret key locally

In understand that the secret key is sent in the clear for being encrypted 
by a master key.

> and send it to PostgreSQL to wrap it using by pg_kmgr_wrap() and save
> it somewhere. Then the user can use the encrypted secret key to
> encrypt data and decrypt data by something like:
>
> INSERT INTO tbl VALUES (pg_encrypt('user data', pg_kmgr_unwrap('xxxxx'));
> SELECT pg_decrypt(secret_column, pg_kmgr_unwrap('xxxxx')) FROM tbl;
>
> Where 'xxxxx' is the result of pg_kmgr_wrap function.

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".

When dealing with cryptography and key management, I can only recommand 
extreme caution.

-- 
Fabien.



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: error context for vacuum to include block number
Next
From: Fabien COELHO
Date:
Subject: Re: psql - add SHOW_ALL_RESULTS option