Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google’s fully homomorphic encryption compiler – a primer

jeremykun.com

Post reply on HN
Print view View original

31–40 of 168 posts

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

#31

Post by j2kun »

squeaky-clean wrote: post #14
fnordpiglet wrote: post #8

Earlier quoted context omitted.

Adding two numbers takes 7 seconds, so many many many But - it’s a lot better than it has been for FHE. This is progress even if it seems absurd.

I'm surprised the "capitalizing a 32 character string" example is actually one second faster than adding two 32bit integers. Still super slow, but I'm curious why. I'd assume that if the string_cap.cc example takes 256 wires, wouldn't add.cc take 64 wires?

Short answer: string cap has more parallelism in the circuit. Depth is more important than total number of gates, and optimizers can decrease depth pretty well.

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

#32

Post by bawolff »

hn_throwaway_99 wrote: post #19
molsongolden wrote: post #12

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…

> "near plaintext speed" fundamentally isn't currently possible with true fully homomorphic encryption, at least in my understanding.

If you skip the security requirements, applying rot13 twice is a fully homomorphic scheme that achieves plaintext speeds ;)

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

#33

Post by j2kun »

fnordpiglet wrote: post #8
7e wrote: post #3

How many orders of magnitude slower is this?

Adding two numbers takes 7 seconds, so many many many But - it’s a lot better than it has been for FHE. This is progress even if it seems absurd.

I probably should have added: the backends used in the post are 3-ish years old and missing some of the latest features. We're working on integrating newer backends and taking advantage of the new techniques! The performance story is better than it seems from my article. Plus this doesn't have any hardware acceleration, another big topic on my agenda :)

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

#35

Post by pmarreck »

bawolff wrote: post #29
molsongolden wrote: post #12

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/

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 still leaves computations on numeric data vulnerable?

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

#36

Post by j2kun »

e12e wrote: post #9

Curious if there's tooling to de/serialize the encryption context? The examples aren't very useful to demonstrate "real" homomorphic encryption in the sense that it takes in plaintext directly; encrypt and transforms; then decrypts - I'd love to see a snub that takes encrypted input (only) and returns ciphertext of the result - that can then be decrypted on a client node provided the correct key? Or is this supposed…

We have some serialization and deseralization to protos for internal tests. It's straightforward, and probably we'll add it to the compiler once we have a strong need and some more stable backends

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

#37

Post by KMag »

hn_throwaway_99 wrote: post #21
whatshisface wrote: post #18

Earlier quoted context omitted.

"Encrypted queries for an encrypted database" could be as straightforward as encrypting both the keys and values using a known public key and putting the results in MySQL. You have to be careful with the claims made around these kinds of things because they often appear to be more complex than they are.

Huh? How would you search on any encrypted fields?

No subfield matches, no comparisons other than == and != on the whole field, and only works with deterministic encryption... so leaks like a sieve under many threat models.

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

#38

Post by Dylan16807 »

pmarreck wrote: post #35
bawolff wrote: 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 statistics do you have in mind there?

If you're using FHE to encrypt a text search, then you'll generate a match/no-match boolean for each character. The server won't know which is which. Then you'd probably OR large blocks of these together, to give you a match/no-match boolean for each segment of text. Then you return all the booleans to the client, who decrypts them.

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

#39

Post by gregschlom »

NovemberWhiskey wrote: post #16
TeMPOraL wrote: post #11

Earlier quoted context omitted.

I feel it's already at the edge of being useful in practice. Compute and memory are cheap, and we're wasting a lot of it - so even with overhead this big, simple calculations wrapped in FHE wouldn't be prohibitively expensive - and may just be useful enough to create new types of software systems.

7 seconds to add two numbers; that's roughly, what, 10 orders of magnitude slower than without FHE? I'm not sure compute is that cheap.

An order of magnitude order of magnitude

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

#40

Post by aliqot »

j2kun wrote: post #33
fnordpiglet wrote: post #8

Earlier quoted context omitted.

Adding two numbers takes 7 seconds, so many many many But - it’s a lot better than it has been for FHE. This is progress even if it seems absurd.

I probably should have added: the backends used in the post are 3-ish years old and missing some of the latest features. We're working on integrating newer backends and taking advantage of the new techniques! The performance story is better than it seems from my article. Plus this doesn't have any hardware acceleration, another big topic on my agenda :)

Hey no need to justify it here, this is really cool! The first few runs are always slow and ready for optimization. I am very optimistic for what this tech may do for medical records and similar industries.
Post reply on HN