Greetings,
* Tal Glo (glozmantal@gmail.com) wrote:
> There is a way to implement full homomorphic encryption (FHE) with
> Postgres. The decision which attributes to encrypt must be done at database
> planning step. It worth mentioning that FHE is good to implement, if one
> wants to be able to do server side supported mathematical operations on the
> encrypted data. If the data just needs to be stored in an encrypted form
> then using FHE might be a storage overkill. A dump of the database with FHE
> encrypted attributes preserves the encryption of the encrypted attributes.
Wasn't it relatively recently pointed out that having the ability to do
mathematical operations on the encrypted data ends up leading someone to
be able to deduce a fair bit of information much more easily than
actually breaking the encryption would involve..?
https://eprint.iacr.org/2016/775.pdf
Not finding it right now but I recall there being another paper which
basically pointed out that if you have context information about the
encrypted data (if it's credit card numbers, or SSNs, or such), along
with the ability to perform some operations (addition, ordering, etc)
that you could derive the real values without that much difficulty.
> 1. The encrypted attributes were big in size and Postgres cannot store the
> FHE cypher texts data type. 20,858 encrypted values used 3,6GB. ~33% of
> that size is because of base64 and the rest of the size ist because of my
> chosen encryption parameters.
A bit confused as to why you'd use base64 to store the data- would make
a lot more sense to use bytea.
> 2. Handling queries related to FHE encrypted attributes on the server side
> requires an implementation of own C language functions.
This could certainly be done in an extension, of course.
Thanks,
Stephen