From: | Sehrope Sarkuni <sehrope(at)jackdb(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Joe Conway <mail(at)joeconway(dot)com>, Antonin Houska <ah(at)cybertec(dot)at>, Stephen Frost <sfrost(at)snowman(dot)net>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, "Moon, Insung" <Moon_Insung_i3(at)lab(dot)ntt(dot)co(dot)jp>, Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS) |
Date: | 2019-07-29 21:53:40 |
Message-ID: | CAH7T-aqwfUwq6rJbyJG7uu=EFbOG2N2bffrNv5iXs9Yqj+H5Pw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jul 29, 2019 at 4:10 PM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
wrote:
> On 2019-Jul-27, Bruce Momjian wrote:
>
> > I think using LSN and page number, we will _never_ reuse the IV, except
> > for cases like promoting two standbys, which I think we have to document
> > as an insecure practice.
>
> Actually, why is it an insecure practice? If you promote two standbys,
> then the encrypted pages are the same pages, so it's not two different
> messages with the same key/IV -- they're still *one* message. And as
> soon as they start getting queries, they will most likely diverge
> because the LSNs of records after the promotion will (most likely) no
> longer match. It takes one different WAL record length for the
> "encryption histories" to diverge completely ...
>
You could have a sequence of post promotion events like:
# Replica 1
LSN=t+0 Operation A
LSN=t+1 Operation B
...
LSN=t+n Operation C
# Replica 2
LSN=t+0 Operation X
LSN=t+1 Operation Y
...
LSN=t+n Operation Z
If the LSN and modified page numbers of C and Z are the same
... and the net effect of Z is known (ex: setting a bunch of bytes on the
row to zero)
... and you can read the encrypted pages of both replicas (ex: have access
to the encrypted storage tier but not necessarily the live server)
... then you can XOR the encrypted pages to get the plain text for the
bytes after operation C.
Yes, it's not likely and yes it has a lot of "if..." involved, but it is
possible.
I don't think this will be an issue in practice, but it should be
documented. Otherwise, it's not unreasonable for someone to expect that a
promoted replica would use be using new keys for everything after each
promotion.
Encryption for WAL can avoid this type of problem entirely by generating a
new random salt and adding a "Use new salt XYZ for WDEK going forward"
record. The two replicas would generate different salts so all subsequent
encrypted WAL data would be different (even the exact same records).
Unfortunately, that doesn't work for pages without a lot more complexity to
keep track of which key version to use based upon the LSN.
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-07-29 21:55:14 | Re: TopoSort() fix |
Previous Message | Thomas Munro | 2019-07-29 21:51:59 | Re: should there be a hard-limit on the number of transactions pending undo? |