On Mon, Jul 08, 2019 at 11:25:10AM -0400, Bruce Momjian wrote:
>On Mon, Jul 8, 2019 at 11:18:01AM -0400, Joe Conway wrote:
>> On 7/8/19 10:19 AM, Bruce Momjian wrote:
>> > When people are asking for multiple keys (not just for key rotation),
>> > they are asking to have multiple keys that can be supplied by users only
>> > when they need to access the data. Yes, the keys are always in the
>> > datbase, but the feature request is that they are only unlocked when the
>> > user needs to access the data. Obviously, that will not work for
>> > autovacuum when the encryption is at the block level.
>>
>> > If the key is always unlocked, there is questionable security value of
>> > having multiple keys, beyond key rotation.
>>
>> That is not true. Having multiple keys also allows you to reduce the
>> amount of data encrypted with a single key, which is desirable because:
>>
>> 1. It makes cryptanalysis more difficult
>> 2. Puts less data at risk if someone gets "lucky" in doing brute force
>
>What systems use multiple keys like that? I know of no website that
>does that. Your arguments seem hypothetical. What is your goal here?
>
I might ask the same question about databases - which databases use an
encryption scheme where the database does not have access to the keys?
Actually, I've already asked this question before ...
The databases I'm familiar with do store all the keys in a vault that's
unlocked during startup, and then users may get keys from it (including
maintenance processes). We could still control access to those keys in
various ways (ACL or whatever), of course.
BTW how do you know this is what users want? Maybe they do, but then
again - maybe they just see it as magic and don't realize the extra
complexity (not just at the database level). In my experience users
generally want more abstract things, like "Ensure data privacy in case
media theft," or "protection against evil DBA".
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
