On Tue, Oct 1, 2019 at 12:19 PM Bruce Momjian <br...@momjian.us> wrote: > Just to give more detail. Initially, there was a desire to store keys > in only one place, either in the file system or in database tables. > However, it became clear that the needs of booting the server and crash > recovery required file system keys, and per-user/db keys were best done > at the SQL level, so that indexing can be used, and logical dumps > contain the locked keys. SQL-level storage allows databases to be > completely independent of other databases in terms of key storage and > usage.
Wait, we're going to store the encryption keys with the database? It seems like you're debating whether to store your front door keys under the doormat or in a fake rock by the side of the path, when what you really ought to be doing is keeping them physically separated from the house, like in your pocket or your purse. It seems to me that the right design is that there's a configurable mechanism for PostgreSQL to request keys from someplace outside the database, and that other place is responsible for storing the keys securely and not losing them. Probably, it's a key-server of some kind running on another machine, but if you really want you can do something insecure instead, like getting them from the local filesystem. I admit I haven't been following the threads on this topic, but this just seems like a really strange idea. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
