Re: Internal key management system
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Fabien COELHO <coelho@cri.ensmp.fr>
Cc: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>, Cary Huang <cary.huang@highgo.ca>, Ahsan Hadi <ahsan.hadi@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, "Moon, Insung" <tsukiwamoon.pgsql@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Sehrope Sarkuni <sehrope@jackdb.com>, cary huang <hcary328@gmail.com>, Ibrar Ahmed <ibrar.ahmad@gmail.com>, Joe Conway <mail@joeconway.com>
Date: 2020-06-10T17:40:45Z
Lists: pgsql-hackers
On Fri, Jun 5, 2020 at 03:34:54PM +0200, Fabien COELHO wrote: > Obviously it requires some more thinking and design, but my point is that > postgres should not hold a KEK, ever, nor presume how DEK are to be managed > by a DMS, and that is not very difficult to achieve by putting it outside of > pg and defining how interactions take place. Providing a reference/example > implementation would be nice as well, and Masahiko-san code can be rewrapped > quite easily. Well, the decrypted keys are already stored in backend memory, so what risk does haveing the KEK in memory for a brief period avoid? -- Bruce Momjian <bruce@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee