Dear Tels.
On Tue, Oct 1, 2019 at 4:33 PM Tels <nospam-pg-abuse@bloodgate.com> wrote:
>
> Moin,
>
> On 2019-09-30 23:26, Bruce Momjian wrote:
> > For full-cluster Transparent Data Encryption (TDE), the current plan is
> > to encrypt all heap and index files, WAL, and all pgsql_tmp (work_mem
> > overflow). The plan is:
> >
> > https://wiki.postgresql.org/wiki/Transparent_Data_Encryption#TODO_for_Full-Cluster_Encryption
> >
> > We don't see much value to encrypting vm, fsm, pg_xact, pg_multixact,
> > or
> > other files. Is that correct? Do any other PGDATA files contain user
> > data?
>
> IMHO the general rule in crypto is: encrypt everything, or don't bother.
>
> If you don't encrypt some things, somebody is going to find loopholes
> and sidechannels
> and partial-plaintext attacks. Just a silly example: If you trick the DB
> into putting only one row per page,
> any "bit-per-page" map suddenly reveals information about a single
> encrypted row that it shouldn't reveal.
>
> Many people with a lot of free time on their hands will sit around,
> drink a nice cup of tea and come up
> with all sorts of attacks on these things that you didn't (and couldn't)
> anticipate now.
This is my thinks, but to minimize overhead, we try not to encrypt
data that does not store confidential data.
And I'm not a security expert, so my thoughts may be wrong.
But isn't it more dangerous to encrypt predictable data?
For example, when encrypting data other than the data entered by the user,
it is possible(maybe..) to predict the plain text data.
And if these data are encrypted, I think that there will be a security problem.
Of course, the encryption key will use separately.
But I thought it would be a problem if there were confidential data
encrypted using the same key as the attacked data.
Best regards.
Moon.
>
> So IMHO it would be much better to err on the side of caution and
> encrypt everything possible.
>
> Best regards,
>
> Tels
>
>