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

21–30 of 168 posts

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

#21

Post by hn_throwaway_99 »

whatshisface wrote: post #18
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/

"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?

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

#22

Post by sillysaurusx »

flangola7 wrote: post #13
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.

If all you need to do is handle a symmetric key exchange that you then use for everything else, that might be enough.

This is tempting to believe, but unfortunately the dream is to be able to run applications on someone else's servers without them knowing what you're doing. That's when I lost interest in FHE. If you want to use it, you have to use it everywhere, and it's just too slow.

Hopefully I'm wrong about that.

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

#23

Post by admax88qqq »

whatshisface wrote: post #18
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/

"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.

lol no it's not.

Up can't do a range on encrypted data. If you encrypt 5 and encrypt 10, how do you expect to compare the encrypted results to see which is greater?

If all you do is key value lookup then sure. But SQL is much richer than that.

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

#24

Post by teraflop »

whatshisface wrote: post #18
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/

"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.

It's not nearly that simple. If your encryption scheme is deterministic then this leaks a ton of information, because anybody with the public key can just encrypt lots of values to reconstruct a mapping between plaintexts and ciphertexts. On the other hand, if your encryption scheme isn't deterministic, then you can't predict what encrypted value you should query for.

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

#25

Post by [deleted] »

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?

[deleted]

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

#26

Post by bahorn »

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/

From their FAQ and blog posts, I don't believe they apply much FHE. Seems what they do is use work from a different subfield [1], which seems to be able to achieve the required speeds and still be able to work with more complex queries.

Techniques I'm seeing in the Pappas et al. paper mentioned in the history section of [1] to do more complex queries seems pretty cool, and I imagine the performance has been improved a bit in more recent work.

[1] https://en.wikipedia.org/wiki/Searchable_symmetric_encryptio...

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

#27

Post by smoldesu »

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/

Proprietary FHE is like doing card magic on a loaded deck. I'm sure there are technical merits to what they're doing, but because they also refuse to show me how the trick is done, I can similarly assume there are some ugly cut corners inside too.

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

#28

Post by unshavedyak »

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.

It would be interesting to see a whole new generation of writing apps with hyper optimized code. We suddenly go back to the 1950s(?) in relative compute power for apps behind FHE.

Not sure what could be done with it at 7s though hah.

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

#29

Post by bawolff »

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 getting the key?

[1] this is very different from FHE where the provider recieves the data already encrypted, and at no point has access to the decryption key.

Edit: their website claims "Data is never decrypted" but then claims they decrypt it before returning it. So its confusing what they are actually doing - but i am 99% sure they are selling bullshit.

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

#30

Post by whatshisface »

teraflop wrote: post #24
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.

It's not nearly that simple. If your encryption scheme is deterministic then this leaks a ton of information, because anybody with the public key can just encrypt lots of values to reconstruct a mapping between plaintexts and ciphertexts. On the other hand, if your encryption scheme isn't deterministic, then you can't predict what encrypted value you should query for.

Those kinds of problems have never stopped any company from offering a service with a lot of nice graphics on the home page.
Post reply on HN