| From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
|---|---|
| To: | Jacob Champion <jchampion(at)timescale(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Transparent column encryption |
| Date: | 2022-08-30 11:53:49 |
| Message-ID: | fae4e479-45d1-e06d-106c-0c5b9daa7a2a@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 27.07.22 01:19, Jacob Champion wrote:
>> Now, if we don't have a padding system
>> built into the feature, then that does put even more on the user; it's
>> hard to argue with that.
> Right. If they can even fix it at all. Having a well-documented padding
> feature would not only help mitigate that, it would conveniently hang a
> big sign on the caveats that exist.
I would be interested in learning more about such padding systems. I
have done a lot of reading for this development project, and I have
never come across a cryptographic approach to hide length differences by
padding. Of course, padding to the block cipher's block size is already
part of the process, but that is done out of necessity, not because you
want to disguise the length. Are there any other methods? I'm
interested to learn more.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2022-08-30 12:16:36 | Re: Postmaster self-deadlock due to PLT linkage resolution |
| Previous Message | Amit Kapila | 2022-08-30 11:51:07 | Re: Perform streaming logical transactions by background workers and parallel apply |