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

101–110 of 168 posts

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

#101

Post by bawolff »

l33t233372 wrote: post #56
bawolff wrote: post #52

Earlier quoted context omitted.

> 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). Those standards are meaningless by themselves without specifying a mode (e.g. GCM, CTR, CBC, ECB, etc). A thing people sometimes try to do with them (no idea if this is what vaulttree is doing) is use some less secure mode that is determistic and do equality matching (th…

ECB should never be used under any circumstances. Library creators would do well to rename their functions along the lines of ECB_NEVER_USE_THIS_IS_NOT_SECURE.

In case it wasn't clear from my comment - i agree 100%

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

#102

Post by bawolff »

pmarreck wrote: post #78
bawolff wrote: post #51

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

Its unclear, but i think they are using client to mean their frontend server. They also say that the user recieves plaintext, and they integrate with cloud key provider services which would make no sense if they aren't using the key.

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

#103

Post by nabla9 »

> It’s roughly a 20,000x overhead.

Would this be a realistic use case?

A wants to send 256 bit message (M) to B.

B sends already encrypted 256-bit AES key (K) to A.

A can use encrypted K to encrypt M and send it to B without knowing K.

(essentially public key symmetric key)

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

#104

Post by apple-sauce »

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…

Are "privacy" issues are more important for people than "dying from cancer" issues though?

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

#105

Post by mxkopy »

golol wrote: post #87

When I first learned about homomorphic encryption it gave me the idea of "cryptographic AI", as some sort of sci-fi writing prompt. Suppose compute is readily available to interstellar civilizations but actually designing a (super)intelligent AI is difficult. Then it could be economically feasible for cryptographic AI to exist. These are descriptions of AIs that run under homomorphic encryption, where the private key…

This premise is very similar to the Dune prequel series. Before FTL travel was discovered, AI dominated the galaxy in the sharded manner you describe. An interesting plot point dealt with what happens if one of these shards doesn't merge for a very long time and develops its own personality.

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

#106

Post by easrng »

3np wrote: post #90
fatneckbeard wrote: post #82

sounds like you could have anonymous currency. heres our FHE bank. we both have accounts. the entire ledger is encrypted. i give you 5 dollars, i have no idea what your starting and ending balance, but i am still able to initiate a transaction that will deduct 5 from mine, and add 5 to yours, and verify i actually have 5 to send, and the entire thing will be done without exchange of information about balances with an…

You don't need FHE for that. It's possible through some zero-knowledge schemes, such as zk-SNARKS, which is implemented in and popularized by shielded transactions on Zcash.

You don't need zk-SNARKS for that. It's possible through some schemes, such as blind signatures, which have been successfully implemented many times but their usage for currency has (iirc) proved legally problematic.

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

#107

Post by eru »

mxkopy wrote: post #105
golol wrote: post #87

When I first learned about homomorphic encryption it gave me the idea of "cryptographic AI", as some sort of sci-fi writing prompt. Suppose compute is readily available to interstellar civilizations but actually designing a (super)intelligent AI is difficult. Then it could be economically feasible for cryptographic AI to exist. These are descriptions of AIs that run under homomorphic encryption, where the private key…

This premise is very similar to the Dune prequel series. Before FTL travel was discovered, AI dominated the galaxy in the sharded manner you describe. An interesting plot point dealt with what happens if one of these shards doesn't merge for a very long time and develops its own personality.

Alas, they are not good books.

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

#108

Post by eru »

aspyct wrote: post #86
CraigJPerry wrote: post #84

Earlier quoted context omitted.

>> since the bank itself could never prove its reserve level of deposit met the percentage set by government There’s no minimum reserve set by the fed anymore: https://www.federalreserve.gov/monetarypolicy/reservereq.htm

Other countries exist.

See https://en.wikipedia.org/wiki/Reserve_requirement

Many countries don't have a reserve requirement. The US was a bit of a laggard.

Minimum reserve requirements were always a bit silly. You want your banks to have a thick capital cushion for its debt. Whether they have reserves on hand is an operational problem they can solve themselves, and doesn't have systemic consequences.

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

#109

Post by [deleted] »

vintermann wrote: post #89
fatneckbeard wrote: post #82

sounds like you could have anonymous currency. heres our FHE bank. we both have accounts. the entire ledger is encrypted. i give you 5 dollars, i have no idea what your starting and ending balance, but i am still able to initiate a transaction that will deduct 5 from mine, and add 5 to yours, and verify i actually have 5 to send, and the entire thing will be done without exchange of information about balances with an…

Sure. And then, after you've transferred 5 dollars to me, I say "What 5 dollars? What are you talking about?" and refuse to hand over the thing that you thought you bought. Add perfect anonymity to the mix and I get to do it over and over again, too.

[deleted]

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

#110

Post by kientuong114 »

5ersi wrote: post #41
teraflop wrote: post #24

Earlier quoted context omitted.

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.

Add random data to it, so that all (equivalent) data is the same length. For example, if you have a four byte field that represents some monetary value, add four more bytes of random data and encrypt it.

How would you run queries over that?
Post reply on HN