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

61–70 of 168 posts

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

#61

Post by squeaky-clean »

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

Earlier quoted context omitted.

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?

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

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

#62

Post by phkahler »

barbazoo wrote: post #57
tossaway0 wrote: post #20

Earlier quoted context omitted.

We've complained long enough about complexity in code being the barrier to speed. Now it's processing power once again. I'll take it if we can rely on the security.

> I'll take it if we can rely on the security. What's a use case here? Will this one day make communication more secure? If so, how?

My bet is on digital currency. Your wallet will be able to send and receive from other wallets locally. Not like crypto. No distributed ledger. You will make transactions locally. You can't just alter your balances though because they are encrypted. Not sure how you get data in or out without keys though. FHE will be a part of such currency though.

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

#63

Post by squeaky-clean »

Dylan16807 wrote: post #43
squeaky-clean wrote: post #14

Earlier quoted context omitted.

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.

No idea lol! Though it says it works on all 32 bytes in parallel regardless of input size. I imagine ignoring the bits that don't change would be some sort of security vulnerability? You could probably work out some timing attack or entropy reduction otherwise? They state it should take the same duration regardless of the length of the input string or how much needs to be capitalized (all branches are executed even though many are discarded)

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

#64

Post by blibliblo »

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"

I could not find on which algorithm this compiler is based at first sight.

I know of an other library for homomorphic encryption Lattigo (https://github.com/tuneinsight/lattigo) which is based on Ring Learning with Errors.

The security of RLWE is "believed" to be strong (meaning there has not been a proof of the opposite yet). It is based on the Lattice problem which is likely to be resistant even to quantum computers.

For a more formal and complete explanation, the paper "A Decade of Lattice Cryptography" was very instructive. https://eprint.iacr.org/2015/939.pdf

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

#65

Post by yafbum »

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 data, their data but still wants to delegate processing to it. This is a very thin space to operate in. It sounds much easier to simply trust a physically separate and controlled computing plant instead of FHE.

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

#66

Post by Dylan16807 »

squeaky-clean wrote: post #63
Dylan16807 wrote: post #43

Earlier quoted context omitted.

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.

No idea lol! Though it says it works on all 32 bytes in parallel regardless of input size. I imagine ignoring the bits that don't change would be some sort of security vulnerability? You could probably work out some timing attack or entropy reduction otherwise? They state it should take the same duration regardless of the length of the input string or how much needs to be capitalized (all branches are executed even t…

> I imagine ignoring the bits that don't change would be some sort of security vulnerability? You could probably work out some timing attack or entropy reduction otherwise?

Nah. The bits are hardcoded into the circuit to not change. That's part of the program, and the program is public information. Only bit 6 of each byte might change, and everyone knows it.

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

#67

Post by fhd2 »

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.

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

#68

Post by jossclimb »

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 being made widely available, at best perhaps OK with a select few groups, but not available to anyone researching this domain.

FHE would solve this, the data can be made available to anyone with compute power that wants to help, while still respecting the privacy of the patients.

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

#70

Post by [deleted] »

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…

[deleted]
Post reply on HN