Live data from Hacker News

Google’s fully homomorphic encryption compiler – a primer

jeremykun.com

11–20 of 168 posts

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

#11
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 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.

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

#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/

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

#13
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.

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

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

#14
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'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?

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

#15
post #3

How many orders of magnitude slower is this?

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

There is something surreal about the last example where you take a Rick Astley video that's 9MB and it becomes 188GB after FHE. That seems like a new category of rick-rolling by some cyberpunk.

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

#16

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

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

#17
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…

There seem to be built-in methods for serializing and deserializing crypto context as well as ciphertexts [0], so it shouldn't be too difficult to build a "complete" example that performs the actual computation in a different application. That said, with a duration of 7 seconds for a simple addition, it is still far from many practical applications, in my opinion.

[0] https://github.com/openfheorg/openfhe-development/blob/main/...

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

#18

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.

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

#19

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 the "encrypted data searchability problem" in the past, but with blind indexes you're still left with the fact that you can only do exact matches - you can't sort the data or use less than/greater than queries.

With true FHE you should be able to sort results, but my understanding is that it's several orders of magnitude slower than plaintext searching, so I'm very curious as to what Vaultree is actually doing.

1. https://medium.com/@joshuakelly/blind-indexes-in-3-minutes-m...

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

#20
post #3

How many orders of magnitude slower is this?

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.

Post reply on HN