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.
Google’s fully homomorphic encryption compiler – a primer
11–20 of 168 posts
Re: Google’s fully homomorphic encryption compiler – a primer
#12I'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.
Re: Google’s fully homomorphic encryption compiler – a primer
#13How 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.
Re: Google’s fully homomorphic encryption compiler – a primer
#14How 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.
Re: Google’s fully homomorphic encryption compiler – a primer
#15How 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
Re: Google’s fully homomorphic encryption compiler – a primer
#16Earlier 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.
Re: Google’s fully homomorphic encryption compiler – a primer
#17Curious 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…
[0] https://github.com/openfheorg/openfhe-development/blob/main/...
Re: Google’s fully homomorphic encryption compiler – a primer
#18Has 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
#19Has 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/
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
#20How 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
I'll take it if we can rely on the security.