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

131–140 of 168 posts

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

#131

Post by ricksunscreen »

macrolime wrote: post #92
vintermann wrote: post #89

Earlier quoted context omitted.

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.

You could set it up so whoever initiates a transfer could get a kind of receipt that proves they initiated a transfer of X dollars to whomever. So if Alice transfers 5 dollars to Bob and Bob says "What 5 dollars? What are you talking about?", then Alice could say, well here's my receipt, that's signed by my private key and the private key of the FHE bank, that shows that I sent the money to Bob and the FHE bank execu…

You get this for free with FHE. In the event of a dispute, you can reveal the randomness and message that produce the public ciphertext given the user's public key.

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

#132

Post by dumbfoundded »

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…

I think cryptographic AI will become a reality. The use-case I was thinking is more of immortality/digitizing human consciousness. If you could be uploaded (like the show Upload), what would that actually look like?

Well, plain text representation would just be too dangerous. Companies could mine your consciousness, duplicate it at will or whatever else they wanted. It's a scary thought. FHE provides the solution.

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

#133

Post by j2kun »

forty wrote: post #60

Is there proof that this is secure? (ie that no information can be found on the plaintext when only having the ciphertext?) I'm hoping something of the like of "this is secure if AES is secure"

It's based on the "Learning With Errors" problem and it's relative, "Ring Learning With Errors", both of which have reductions to lattice crypto problems, the same sort that are in the new NIST proposals for post quantum cryptography. See this article for some more info about how security is evaluated: https://jeremykun.com/2022/12/28/estimating-the-security-of-...

That said, the compiler itself doesn't use any crypto. It generates code for a backend API, and the backend implements the FHE scheme

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

#134

Post by j2kun »

squeaky-clean wrote: post #61
j2kun wrote: post #31

Earlier quoted context omitted.

Short answer: string cap has more parallelism in the circuit. Depth is more important than total number of gates, and optimizers can decrease depth pretty well.

Thanks (and Dylan18607). So to continue assuming, the number of wires specified is just the input/output, and the add.cc has more intermediate "wires"?

It's more like: to implement add you need a ripple carry adder. You can't evaluate bit 6 until you've evaluated bits 1-5. So there's a nested dependence that makes the circuit deep. String cap, on the other hand, can be implemented in parallel by looking at pairs of characters independently. So that makes it into a parallel band of small circuits, which we can evaluate in different CPU cores. Also I think the capitalization operation also affects fewer bits of a char (it's just toggling one bit in each char, IIRC).

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

#135

Post by antognini »

I have a very basic question about fully homomorphic encryption. As I understand it, the encryption scheme ensures that an adversary who has access to the physical computer cannot determine what data the computer program is operating on, even by inspecting the physical states of the machine.

My question is whether or not it is possible for the adversary to determine what computer program is being run. To use the example provided by the post, it is not possible to determine which two integers are being added --- but is it possible to know that the computer is running a program that is adding two integers?

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

#136

Post by edflsafoiewq »

TheGeminon wrote: post #124
edflsafoiewq wrote: post #71

Earlier quoted context omitted.

How exactly would FHE work here?

One example would be a project like Folding@Home but with much more sensitive/personal information. Organizations/universities could compute on data provided by a custodian organization without having to care about data handling.

No, I mean please explain the way you would use FHE to do that.

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

#137

Post by anthk »

j2kun wrote: post #134
squeaky-clean wrote: post #61

Earlier quoted context omitted.

Thanks (and Dylan18607). So to continue assuming, the number of wires specified is just the input/output, and the add.cc has more intermediate "wires"?

It's more like: to implement add you need a ripple carry adder. You can't evaluate bit 6 until you've evaluated bits 1-5. So there's a nested dependence that makes the circuit deep. String cap, on the other hand, can be implemented in parallel by looking at pairs of characters independently. So that makes it into a parallel band of small circuits, which we can evaluate in different CPU cores. Also I think the capital…

It's faster to carry six glasses at once than having to carry them to some point one by one.

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

#138

Post by yafbum »

fhd2 wrote: post #67
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…

I've been working in the privacy space for a few years and always had the same opinion. If a customer doesn't trust the data processor, the logical conclusion is to not send any sensitive data at all, which is technically possible. But it means more edge processing, more client side processing, most likely not what Google wants. But they have to do _something_, even if nobody uses it in the end.

The practical way that people deal with this is putting a swarm of auditors all up in the processors' business. It used to be this way for telecom as well: to know whether comms were secure, you needed to walk the length of the cable and look for taps. Comms encryption has radically changed this. The question is, is there a similar revolution in the making for processing as opposed to comms. I strongly doubt the benefits will outweigh the drawbacks.

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

#139

Post by ChadNauseam »

antognini wrote: post #135

I have a very basic question about fully homomorphic encryption. As I understand it, the encryption scheme ensures that an adversary who has access to the physical computer cannot determine what data the computer program is operating on, even by inspecting the physical states of the machine. My question is whether or not it is possible for the adversary to determine what computer program is being run. To use the exam…

It is possible to determine what algorithm is being run. To prevent that as best as possible, you want Indistinguishability Obfuscation.

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

#140

Post by DesiLurker »

fnordpiglet wrote: post #44
j2kun wrote: post #33

Earlier quoted context omitted.

I probably should have added: the backends used in the post are 3-ish years old and missing some of the latest features. We're working on integrating newer backends and taking advantage of the new techniques! The performance story is better than it seems from my article. Plus this doesn't have any hardware acceleration, another big topic on my agenda :)

Yeah I’ve always wondered if FHE would benefit from asic level acceleration, or at least FPGA

If you are going to do an asic (w/o data going to memory IO) then why not use regular encryption with codec on the SoC itself (like DRM content). that works just fine. IMO the main value here would be trust between unknown parties over untrusted medium.
Post reply on HN