Re: Internal key management system

From: Bruce Momjian <bruce(dot)momjian(at)enterprisedb(dot)com>
To: Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>
Cc: "Moon, Insung" <tsukiwamoon(dot)pgsql(at)gmail(dot)com>, Cary Huang <cary(dot)huang(at)highgo(dot)ca>, Robert Haas <robertmhaas(at)gmail(dot)com>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Sehrope Sarkuni <sehrope(at)jackdb(dot)com>, cary huang <hcary328(at)gmail(dot)com>, Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>, Joe Conway <mail(at)joeconway(dot)com>
Subject: Re: Internal key management system
Date: 2020-03-11 23:13:44
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Fri, Mar 6, 2020 at 03:31:00PM +0900, Masahiko Sawada wrote:
> On Fri, 6 Mar 2020 at 15:25, Moon, Insung <tsukiwamoon(dot)pgsql(at)gmail(dot)com> 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?
> >
> Thank you! I'd attached wrong file.

Looking at this thread, I wanted to make a few comments:

Everyone seems to think pgcrypto need some maintenance. Who would like
to take on that task?

This feature does require openssl since all the encryption/decryption
happen via openssl function calls.

Three are three levels of encrypt here:

1. The master key generated during initdb

2. The passphrase to unlock the master key at boot time. Is that
optional or required?

3. The wrap/unwrap key, which can be per-user/application/cluster

In the patch, the doc heading "Cluster Encryption Key Rotation" seems
confusing. Doesn't that change the pass phrase? Why refer to it as the
cluster encryption key here?

Could the wrap functions expose the master encryption key by passing in
empty string or null? I wonder if we should create a derived key from
the master key to use for pg_wrap/pg_unwrap, maybe by appending a fixed
string to all strings supplied to these functions. We could create
another derived key for use in block-level encryption, so we are sure
the two key spaces would never overlap.

pgcryptokey shows a method for creating a secret between client and
server using SQL that does not expose the secret in the server logs:

I assume we will create a 256-bit key for the master key, but give users
an option of 128-bit vs 256-bit keys for block-level encryption.
256-bit keys are considered necessary for security against future
quantum computing attacks.

This looks like a bug in the patch:

- This parameter can only be set in the <filename>postgresql.conf</filename>
+ This parameter can only be set in the <filename>postgresql.confo</filename>

Bruce Momjian <bruce(at)momjian(dot)us>

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Paul A Jungwirth 2020-03-11 23:27:53 Re: SQL:2011 PERIODS vs Postgres Ranges?
Previous Message Nikita Glukhov 2020-03-11 23:09:44 Re: SQL/JSON: functions