|From:||Robert Haas <robertmhaas(at)gmail(dot)com>|
|To:||Joe Conway <mail(at)joeconway(dot)com>|
|Cc:||Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, "Moon, Insung" <Moon_Insung_i3(at)lab(dot)ntt(dot)co(dot)jp>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)|
|Views:||Raw Message | Whole Thread | Download mbox|
On Mon, Jun 18, 2018 at 10:12 AM, Joe Conway <mail(at)joeconway(dot)com> wrote:
> Not necessarily. Our pages probably have enough predictable bytes to aid
> cryptanalysis, compared to user data in a column which might not be very
Really? I would guess that the amount of entropy in a page is WAY
higher than in an individual column value.
> But in any case most encryption schemes use a random nonce (salt) to
> ensure two identical strings do not encrypt to the same result. And
> often the encrypted length is padded, so while you might be able to
> infer short versus long, you would not usually be able to infer the
> exact plaintext length.
Sure, that could be done, although it means that equality comparisons
must be done unencrypted.
> Again completely dependent on the extension you use to do the encryption
> for the input policy. The keys don't need to be stored with the data,
> and the decryption can be transparent only for certain users or if
> certain session variables exist which the DBA does not have access to.
Not arguing with that. And to be clear, I'm not trying to attack your
proposal. I'm just trying to have a discussion about advantages and
disadvantages of different approaches.
The Enterprise PostgreSQL Company
|Next Message||Ildus Kurbangaliev||2018-06-18 14:30:45||Re: [HACKERS] Custom compression methods|
|Previous Message||Tom Lane||2018-06-18 14:20:19||Re: Slow planning time for simple query|