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

71–80 of 168 posts

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

#71

Post by edflsafoiewq »

jossclimb wrote: post #68
yafbum wrote: post #65

The application domain for this stuff is so negligible... Who's going to pay for this huge added cost? Either the customer whose data is being handled trusts the service provider enough to let it handle unencrypted data, in which case all the data is vulnerable to interception (and the vast majority of data processing falls into this category) Or the customer doesn't trust the data processor to see the unencrypted da…

That's not the only trust model at play. Here is a different example of where FHE becomes very useful. Cancer researchers will benefit greatly from patient data sets that might include very privacy centric elements such as genome sets, past medical history (of both them and relatives to help understand heredity aspects of the disease). Most people making an informed decision may be uncomfortable with this information…

How exactly would FHE work here?

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

#72

Post by radicalbyte »

yafbum wrote: post #65

The application domain for this stuff is so negligible... Who's going to pay for this huge added cost? Either the customer whose data is being handled trusts the service provider enough to let it handle unencrypted data, in which case all the data is vulnerable to interception (and the vast majority of data processing falls into this category) Or the customer doesn't trust the data processor to see the unencrypted da…

It also doesn't work for GDPR as legally encrypted personal information is still personal information. Just because you can't decode it today doesn't mean that you won't be able to decode it tomorrow (via key leak, quantum etc etc).

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

#73

Post by lwansbrough »

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/

Let’s put it this way.. if they had actually cracked true FHE, they wouldn’t be a company anymore having been bought by the US government for billions of dollars.

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

#74

Post by amadvance »

admax88qqq wrote: post #23
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.

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.

Even lookup is not easy to be done securely. You don't want that a malicious server/database knows that you are accessing always that record.

See this discussion about how to achieve that: https://news.ycombinator.com/item?id=31668814

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

#75

Post by CGamesPlay »

Hmm, given that "mov is Turing-complete" [0], is it possible to get around the requirement that loops must be fully unrolled? Obviously you couldn't tell if your algorithm was finished, but if you could ask the key holder if the algorithm had completed or needed more work, you could theoretically compute any algorithm. What am I missing?

[append] Perhaps, could you create a "fully homomorphically encrypted" 6502, where each application of the program corresponded with a single clock of the emulated microprocessor?

[0] https://drwho.virtadpt.net/files/mov.pdf

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

#76

Post by amelius »

yafbum wrote: post #65

The application domain for this stuff is so negligible... Who's going to pay for this huge added cost? Either the customer whose data is being handled trusts the service provider enough to let it handle unencrypted data, in which case all the data is vulnerable to interception (and the vast majority of data processing falls into this category) Or the customer doesn't trust the data processor to see the unencrypted da…

> The application domain for this stuff is so negligible...

They said the same about Rust ("it's a systems language, needlessly complicated for large user applications").

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

#77

Post by pmarreck »

hn_throwaway_99 wrote: post #54
pmarreck wrote: post #35

Earlier quoted context omitted.

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.

Right, but this service isn't advertising FHE.

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

#78

Post by pmarreck »

bawolff wrote: post #51
pmarreck wrote: post #35

Earlier quoted context omitted.

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…

Why would they need the key? It says everything's encrypted/decrypted on the client. If they did encrypted-token indexing server-side, they wouldn't need to decrypt. Agreed that this scheme would eventually leak too much information.

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

#79

Post by hectormalot »

yarg wrote: post #47
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/

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…

How I read it is that you specify which ways you will use a column and then VT will create the various encrypted columns to support this. Deterministic shared key for matches only. Ordered encryption for ranges and FHE for various calculations. The latter probably being quite slow. I don’t think they are rolling their own crypto, just combining a lot of existing algorithms in various ways.

I could see a use cases in either defense in depth and/or storing data in the cloud while having your keys somewhere else.

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

#80

Post by smasher164 »

CGamesPlay wrote: post #75

Hmm, given that "mov is Turing-complete" [0], is it possible to get around the requirement that loops must be fully unrolled? Obviously you couldn't tell if your algorithm was finished, but if you could ask the key holder if the algorithm had completed or needed more work, you could theoretically compute any algorithm. What am I missing? [append] Perhaps, could you create a "fully homomorphically encrypted" 6502, whe…

Combinatorial circuits aren't turing complete. The novelty of mov being turing complete is that they were able to do conditional branching with just loads and stores. In the FHE case, they can't read and write to parts of memory, so it's a no-go.

This is why their compiler essentially only works on pure functions whose inputs have a statically known size.

Post reply on HN