Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
От | Tomas Vondra |
---|---|
Тема | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) |
Дата | |
Msg-id | 20190716000458.rve3tklg7j7yuycm@development обсуждение исходный текст |
Ответ на | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS) (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: [Proposal] Table-level Transparent Data Encryption (TDE) and KeyManagement Service (KMS)
|
Список | pgsql-hackers |
On Mon, Jul 15, 2019 at 06:05:37PM -0400, Bruce Momjian wrote: >On Mon, Jul 15, 2019 at 10:44:34PM +0200, Tomas Vondra wrote: >> On Mon, Jul 15, 2019 at 03:55:38PM -0400, Bruce Momjian wrote: >> > The crazy seems more sane now --- "encrypt the page with CRC contents as >> > zero" (which we probably already do to compute the CRC), then compute >> > the CRC, and modify the page CRC. >> > >> >> Huh? So you want to >> >> 1) set CRC to 0 >> 2) encrypt the page >> 3) compute CRC >> 4) set CRC to value computed in (3) >> 5) encrypt the page again >> >> That seems pretty awful from performance POV, and it does not really >> solve much as we'd still need to decrypt the page while verifying the >> checksums (because the CRC is in the page header, which is encrypted). > >No, I was thinking we would overwrite whatever the encrypted output was >in the spot that has the CRC with the computed CRC. Yeah, sounds even >crazier now that I said it --- never mind. > Uh, how could that possibly work? Symmetric ciphers are "diffusing" the bits within the block, i.e. replacing 16 bits in a 128-bit ciphertext block will affect the whole plaintext block, not just the matching 16 bits of plaintext. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: