Re: Internal key management system
От | Bruce Momjian |
---|---|
Тема | Re: Internal key management system |
Дата | |
Msg-id | 20200321140102.GF10066@momjian.us обсуждение исходный текст |
Ответ на | Re: Internal key management system (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>) |
Ответы |
Re: Internal key management system
|
Список | pgsql-hackers |
On Sat, Mar 21, 2020 at 02:12:46PM +0900, Masahiko Sawada wrote: > On Sat, 21 Mar 2020 at 05:30, Bruce Momjian <bruce@momjian.us> 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 can be rotated and migrated to a different > > cluster independently. For example, users might want to create a new > > cluster with a new block-level key, but might want to copy the SQL-level > > key from the old cluster to the new cluster. Both keys would be > > unlocked with the same passphrase. > > I've updated the patch according to yesterday's meeting. As the above > description by Bruce, the current patch have two encryption keys. > Previously we have the master key in pg_control but due to exceeding > the safe size limit of pg_control I moved two keys to the dedicated > file located at global/pg_key. A wrapped key is 128 bytes and the > total size including two wrapped key became 552 bytes while safe limit > is 512 bytes. > > During pg_upgrade we copy the key file from the old cluster to the new > cluster. Therefore we can unwrap the data that is wrapped on the old > cluster on the new cluster. I wonder if we should just use two files, one for each key. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
В списке pgsql-hackers по дате отправления: