Live data from Hacker News

Google’s fully homomorphic encryption compiler – a primer

jeremykun.com

51–60 of 168 posts

Re: Google’s fully homomorphic encryption compiler – a primer

#51
post #29

Earlier quoted context omitted.

They figured out that most people just look for buzzwords and are thus easy to separate from their money when it comes to crypto. Encryption as a service is non-sencical. If the provider has the key, and does the encryption and decryption, then who are you protecting the data from[1]? What magical malicious person are you imagining that would somehow be able to get their hands on the encrypted data without also getti…

It seems like what they do (maybe?) is encrypt the binary/string data but still let you search or join on it by encrypting queries to the same data? So in other words the operations on the data are not encrypted but the data itself is? This might work for whole words but for partial word matches I think you'd have to do a byte-for-byte character swap which exposes it too much to statistical cryptanalysis? And this st…

> It seems like what they do (maybe?) is encrypt the binary/string data but still let you search or join on it by encrypting queries to the same data? So in other words the operations on the data are not encrypted but the data itself is?

Are you saying something along the lines of - they split the data in to tokens, deterministically (no iv) encrypt each token, and then do equality comparisons on the encrypted tokens?

Maybe, and it would explain why they say you can chose a cipher and then list a bunch of standard symmetric ciphers. However such schemes usually leak too much in practise (even at the granuality of whole words).

More importantly, it really doesn't matter. They have both the key and the encrypted data. If someone hacks their system, the best encryption in the world won't help if the attacker steals both.

Re: Google’s fully homomorphic encryption compiler – a primer

#52
post #47

Has anyone used Vaultree[0]? Their product is FHE-as-a-Service and they claim "near plaintext speed". I've seen a few FHE posts roll across the front page recently and they all make me think of Vaultree because they sound like they've got it sorted. [0] https://www.vaultree.com/how-it-works/

FHE @ plain text speed? Absolute bullshit. > You choose the encryption standard in use for the database, from AES, DES, 3DES, Blowfish, Twofish, Skipjack, and more. That seems very wrong ((as far as I know) those standards are not in any way designed in such a way as to permit operations on their cyphertexts). > Vaultree has achieved major breakthroughs in several encryption technologies, allowing organisations to pr…

> That seems very wrong ((as far as I know) those standards are not in any way designed in such a way as to permit operations on their cyphertexts).

Those standards are meaningless by themselves without specifying a mode (e.g. GCM, CTR, CBC, ECB, etc). A thing people sometimes try to do with them (no idea if this is what vaulttree is doing) is use some less secure mode that is determistic and do equality matching (this is almost always a bad idea and usually leaks way more than you would naively assume). For example, if you use ECB mode you can search as long as you are searching along block boundries.

https://www.microsoft.com/en-us/research/wp-content/uploads/... is an interesting paper about this sort of thing.

Re: Google’s fully homomorphic encryption compiler – a primer

#53
post #52
post #47

Earlier quoted context omitted.

FHE @ plain text speed? Absolute bullshit. > You choose the encryption standard in use for the database, from AES, DES, 3DES, Blowfish, Twofish, Skipjack, and more. That seems very wrong ((as far as I know) those standards are not in any way designed in such a way as to permit operations on their cyphertexts). > Vaultree has achieved major breakthroughs in several encryption technologies, allowing organisations to pr…

> That seems very wrong ((as far as I know) those standards are not in any way designed in such a way as to permit operations on their cyphertexts). Those standards are meaningless by themselves without specifying a mode (e.g. GCM, CTR, CBC, ECB, etc). A thing people sometimes try to do with them (no idea if this is what vaulttree is doing) is use some less secure mode that is determistic and do equality matching (th…

https://upload.wikimedia.org/wikipedia/commons/f/f0/Tux_ecb....

Re: Google’s fully homomorphic encryption compiler – a primer

#54
post #29

Earlier quoted context omitted.

They figured out that most people just look for buzzwords and are thus easy to separate from their money when it comes to crypto. Encryption as a service is non-sencical. If the provider has the key, and does the encryption and decryption, then who are you protecting the data from[1]? What magical malicious person are you imagining that would somehow be able to get their hands on the encrypted data without also getti…

It seems like what they do (maybe?) is encrypt the binary/string data but still let you search or join on it by encrypting queries to the same data? So in other words the operations on the data are not encrypted but the data itself is? This might work for whole words but for partial word matches I think you'd have to do a byte-for-byte character swap which exposes it too much to statistical cryptanalysis? And this st…

What you are describing is basically a blind index (search for it, there are lots of good resources online). Blind indexes can be quite useful, but they have a number of limitations - the partial match issue as you point out, but also you cannot do range queries or sorting, and they leak some information (e.g. duplicates have the same index value). Blind indexes are most definitely not fully homomorphic encryption.

Re: Google’s fully homomorphic encryption compiler – a primer

#55

Has anyone used Vaultree[0]? Their product is FHE-as-a-Service and they claim "near plaintext speed". I've seen a few FHE posts roll across the front page recently and they all make me think of Vaultree because they sound like they've got it sorted. [0] https://www.vaultree.com/how-it-works/

I'm really, really curious to how it actually works under the covers. Needless to say, I'm sceptical, primarily because "near plaintext speed" fundamentally isn't currently possible with true fully homomorphic encryption, at least in my understanding. For example, they give an example of running queries against data that is never decrypted. I'm very curious as to how they do this. I've used blind indexes [1] to solve…

It's up to them to define "near", but I'd consider https://spiralwiki.com/ (Samir Menon and Prof. David Wu at UT Austin) "nearly" usable compared to regular wikipedia.

Re: Google’s fully homomorphic encryption compiler – a primer

#56
post #52
post #47

Earlier quoted context omitted.

FHE @ plain text speed? Absolute bullshit. > You choose the encryption standard in use for the database, from AES, DES, 3DES, Blowfish, Twofish, Skipjack, and more. That seems very wrong ((as far as I know) those standards are not in any way designed in such a way as to permit operations on their cyphertexts). > Vaultree has achieved major breakthroughs in several encryption technologies, allowing organisations to pr…

> That seems very wrong ((as far as I know) those standards are not in any way designed in such a way as to permit operations on their cyphertexts). Those standards are meaningless by themselves without specifying a mode (e.g. GCM, CTR, CBC, ECB, etc). A thing people sometimes try to do with them (no idea if this is what vaulttree is doing) is use some less secure mode that is determistic and do equality matching (th…

ECB should never be used under any circumstances. Library creators would do well to rename their functions along the lines of ECB_NEVER_USE_THIS_IS_NOT_SECURE.

Re: Google’s fully homomorphic encryption compiler – a primer

#57

Earlier quoted context omitted.

author shows a program that adds two integers and takes 7 seconds to run, and the way the system processes data results in 20000x the RAM usage

We've complained long enough about complexity in code being the barrier to speed. Now it's processing power once again. I'll take it if we can rely on the security.

> I'll take it if we can rely on the security.

What's a use case here? Will this one day make communication more secure? If so, how?

Re: Google’s fully homomorphic encryption compiler – a primer

#58
> Finally, encrypting each bit of a plaintext message comes with major tax on space usage. Each encryption of a single bit corresponds to a list of roughly 700 32-bit integers. If you want to encrypt a 100×100 pixel greyscale image, each pixel of which is an 8-bit integer (0-255), it will cost you 218 MiB to store all the pixels in memory. It’s roughly a 20,000x overhead. For comparison, the music video for Rick Astley’s “Never Gonna Give You Up” at 360p is about 9 MiB (pretty small for a 3 minute video!), but encrypted in FHE would be 188 GiB, which (generously) corresponds to 20 feature-length films at 1080p.

Ouch.

Re: Google’s fully homomorphic encryption compiler – a primer

#59
post #58

> Finally, encrypting each bit of a plaintext message comes with major tax on space usage. Each encryption of a single bit corresponds to a list of roughly 700 32-bit integers. If you want to encrypt a 100×100 pixel greyscale image, each pixel of which is an 8-bit integer (0-255), it will cost you 218 MiB to store all the pixels in memory. It’s roughly a 20,000x overhead. For comparison, the music video for Rick Astl…

[deleted]
Post reply on HN