Live data from Hacker News

Google’s fully homomorphic encryption compiler – a primer

jeremykun.com

141–150 of 168 posts

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

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

It sounds like a soul

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

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

Would that enable continuations or lightweight checkpoint restore? If computation takes hours or weeks you might want to do add some restart-ability...

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

#144

> First, the subset of C++ supported by the compiler is rather small. As mentioned earlier, all data needs to have static sizes. This means, e.g., you can’t write a program that processes arbitrary images. Instead, you have to pick an upper bound on the image size, zero-pad the image appropriately before encrypting it, and then write the program to operate on that image size. In the same vein, the integer types you c…

Admitting the possibility of having multiple frontend languages for the compiler is a longer term goal of mine!

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

#145

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…

What purpose would this serve? Just anonymity for the sake of anonymity, or something else?

Note: this was a genuine question, with genuine interest in the answer. Why the downvotes?

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

#146

Earlier quoted context omitted.

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.

The typical perceived use case is FHE in cloud providers providing highly sensitive compute in a multi tenant platform. In something like that full on hardware acceleration is key

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

#147

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…

I love/hate this. It's one of those ideas that's incredibly appealing to people who already have other ways of doing it, and incomprehensible to people who would actually benefit from it. Most things of that ilk get blown up because once it's peddled to the masses, consumers don't verify that it's actually run the way it's supposed to be run, and someone writes in a backdoor (FTX). Then it just takes a few hyped up c…

> You could finally rely on client-side processing to deal poker hands and process game states without a central server, for example.

Interesting. I had given up on that idea. Not just for poker, but MMOs n stuff. Figured anything of importance had to run server-side.

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

#148

Earlier quoted context omitted.

Check out the Hyperion cantos by Dan Simmons.

That's funny, I started with Hyperion two weeks ago. I like it :)

First book in style of Canterbury tales is fantastic! Remembering Hyperion while that Google engineer though their AI is sentient left me quite uneasy last June.

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

#150

Earlier quoted context omitted.

I love/hate this. It's one of those ideas that's incredibly appealing to people who already have other ways of doing it, and incomprehensible to people who would actually benefit from it. Most things of that ilk get blown up because once it's peddled to the masses, consumers don't verify that it's actually run the way it's supposed to be run, and someone writes in a backdoor (FTX). Then it just takes a few hyped up c…

> You could finally rely on client-side processing to deal poker hands and process game states without a central server, for example. Interesting. I had given up on that idea. Not just for poker, but MMOs n stuff. Figured anything of importance had to run server-side.

it does. But if you could drop an encrypted VM on each client - where the instructions and responses were encrypted, and even frozen/dumped states were encrypted... you'd finally have no need for centralized game servers to arbitrate who sees which part of a hidden state. You could put every player's secrets, and the secrets of the game state, on each client and use their processing in parallel.
Post reply on HN