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

41–50 of 168 posts

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

#41

Post by 5ersi »

teraflop wrote: post #24
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.

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.

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

#43

Post by Dylan16807 »

squeaky-clean wrote: post #14
fnordpiglet wrote: post #8

Earlier 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'm surprised the "capitalizing a 32 character string" example is actually one second faster than adding two 32bit integers. Still super slow, but I'm curious why. I'd assume that if the string_cap.cc example takes 256 wires, wouldn't add.cc take 64 wires?

Since it encrypts one bit at a time, does capitalizing even have to touch the 224 bits that don't change?

> wouldn't add.cc take 64 wires?

Plus another hundred intermediate wires. And it's doing more complicated operations, however much that matters.

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

#44

Post by fnordpiglet »

j2kun wrote: post #33
fnordpiglet wrote: post #8

Earlier 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 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

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

#45

Post by fnordpiglet »

__MatrixMan__ wrote: post #42
fnordpiglet wrote: post #10

Someone needs to make a crypto network that runs submitted FHE programs as proof of work.

What's to stop somebody who knows the cleartext (because they submitted the job) from cheating?

They would presumably pay for the computations on the network (by paying gas). The output would be still encrypted with the FHE public key and can be signed. Having the clear text is the same as having the private key. How would someone cheat? I’ll admit I’m no crypto nerd but I’m not sure how you would cheat.

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

#46

Post by fnordpiglet »

j2kun wrote: post #33
fnordpiglet wrote: post #8

Earlier 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 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 :)

Great article btw

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

#47

Post by yarg »

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 process fully encrypted data at near plaintext speed and keep their data safe even in case of a leak.

That seems even wronger (security via obscurity at best).

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

#48

Post by ricksunscreen »

fnordpiglet wrote: post #8
7e wrote: post #3

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.

Binary TFHE (the scheme the Google compiler uses) is fairly slow and has very large public keys (like 100MB). However the advantage is that binary computation is very flexible and well understood. Additionally, TFHE supports fast (~10ms) bootstrapping, which allows you to perform an arbitrary amount of computation.

If you can live with the limitations of other schemes FHE can be much faster. On a single core of an M1 Macbook Air, multiplying 2 BFV encrypted 4096-bit values takes 4ms and adding them takes only 15us. Additionally, key sizes aren't horrendous (<500kB). One downside with this scheme are that bootstrapping takes minutes so it isn't really practical. This limits the amount of computation you can do before you exceed your noise budget and the ciphertext decrypts to garbage. The other downside is that arithmetic circuits make some computations far more difficult (e.g. comparisons).

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

#49

Post by fnordpiglet »

gregschlom wrote: post #39
NovemberWhiskey wrote: post #16

Earlier quoted context omitted.

7 seconds to add two numbers; that's roughly, what, 10 orders of magnitude slower than without FHE? I'm not sure compute is that cheap.

An order of magnitude order of magnitude

It’s orders of magnitude all the way down

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

#50

Post by friend_and_foe »

fnordpiglet wrote: post #45
__MatrixMan__ wrote: post #42

Earlier quoted context omitted.

What's to stop somebody who knows the cleartext (because they submitted the job) from cheating?

They would presumably pay for the computations on the network (by paying gas). The output would be still encrypted with the FHE public key and can be signed. Having the clear text is the same as having the private key. How would someone cheat? I’ll admit I’m no crypto nerd but I’m not sure how you would cheat.

They'd pay themselves for computation on the network? You can't see a game theoretical problem with this?

If simply encrencrypting the output is less work than running the computation on the ciphertext input, they'll do that and publish the encrypted output as proof. This would mean alliners would up bid for the computation because they know that if their computation becomes the limiting factor in block creation they can beat everyone else to it.

There's also the problem of benefitting from mining. Mining has to only be useful in that it is used to construct blocks, if it is useful for any other purpose whatsoever, whoever benefits from that purpose has an opportunity to mine at lower marginal cost than other miners.

Post reply on HN