Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Rise of Fully Homomorphic Encryption

queue.acm.org

Post reply on HN
Print view View original

81–90 of 132 posts

Re: The Rise of Fully Homomorphic Encryption

#81

Post by wazoox »

hinkley wrote: post #74
wazoox wrote: post #65

I've just watched a presentation about Cosmian ( https://cosmian.com/ ) and their solution boasts using FHE, at a significant price though: computations and queries are about 1000 slower than on unencrypted data according to their CTO. I was quite impressed that it even works at all, though :)

Don’t those sorts of differences suggest that perhaps enclave decryption would be as fast and support more functionality?

Probably but the main objective is to keep data safe in the cloud while keeping everything encrypted (traffic and data), all the time.

Re: The Rise of Fully Homomorphic Encryption

#82

Post by rhindi »

fudgefactorfive wrote: post #45

I think the killer app for FHE is an Ethereum-esque Globally distributed VM (yes eye-roll I hate Crypto/Blockchain nonsense as well). To me that was always the big interesting concept behind Ethereum, running some sort of code with persistent state. Obviously no free lunches so we gotta pay for that somehow to incentivize people to pay for power on computing equipment they aren't personally utilizing. But somehow "cr…

Multiple teams are working on FHE smart contracts, including us, so it’s definitely happening. Adding ZK to the mix would be awesome for scalability and indeed to avoid replicating the FHE computation

Re: The Rise of Fully Homomorphic Encryption

#84

Post by blintz »

anonporridge wrote: post #79

Spiral is an interesting use case of FME for database fetching that just popped up, https://usespiral.com/ General FME computation is obviously not likely to be practical or cost effective any time soon, but there may be some specific use cases, like querying a database, where hiding the information you want to know from the server is advantageous. There are adversarial environments where knowing the information your…

Happy to answer any questions! Yeah, we're taking a narrow application (fetching from a database) and making it really practical. You can privately check a Bitcoin balance at https://btc.usespiral.com or privately read Wikipedia at https://spiralwiki.com. Our code for the Bitcoin site is at https://github.com/spiralprivacy/clients.

Re: The Rise of Fully Homomorphic Encryption

#85

Post by hinkley »

bawolff wrote: post #78
hinkley wrote: post #76

Earlier quoted context omitted.

Doesn’t fully homomorphic encryption have the Tux Image problem cited in block cypher discussions? With a symmetric cipher, I could figure out the blood type of every employee pretty easily. With an asymmetric cipher, I could figure out everyone who has my blood type, and the blood types of anyone who reveals that information. If the point is to filter data when you aren’t allowed to know what the data is, then the a…

I think you are mixing it up with order-preserving encryption and other stuff related to encrypted databases. In the FHE model, the assumption usually is - you have some data, someone else does some encrypted calculations, you get the encrypted answer back, you decrypt the answer and read it. The adversary cannot play 20 questions because they only calculate the encrypted answers, they are not allowed to see what the…

Ah, right, I'd forgotten that bit. Dumb server, smart clients.

Re: The Rise of Fully Homomorphic Encryption

#86

Post by foobiekr »

hinkley wrote: post #76
bawolff wrote: post #4

This feels more like a press release than an actually insightful article. Would practical FHE be interesting? Sure. Is it happening? Doesn't seem like it is any time soon.

Doesn’t fully homomorphic encryption have the Tux Image problem cited in block cypher discussions? With a symmetric cipher, I could figure out the blood type of every employee pretty easily. With an asymmetric cipher, I could figure out everyone who has my blood type, and the blood types of anyone who reveals that information. If the point is to filter data when you aren’t allowed to know what the data is, then the a…

I think you are thinking of how ECB ends up with the identical blocks having identical encrypted form due to key and IV reuse. I don't think this is a requirement for all forms of FHE.

Re: The Rise of Fully Homomorphic Encryption

#87

Post by stjohnswarts »

simiones wrote: post #30
api wrote: post #13

Earlier quoted context omitted.

To make it fast I think we'll need custom silicon. I wonder how many stealth startups exist working on FHE chips?

This isn't a problem that silicon can fix. FHE requires orders of magnitude more operations to be done, and/or more complex operations, to achieve the same results. GP silicon already runs these operations as fast as possible, it's just that there are too many of them, and they are not even parallelizable.

I was gonna say, but yeah if you can't make it more parallel, then yeah custom silicon definitely would bottleneck on that. TBF I know nothing about this, but I have done a lot of parallelization and speeds up of algos on FPGA that are relatively easy to parallelize and seen tremendous speed ups over general purpose CPUs.

Re: The Rise of Fully Homomorphic Encryption

#88

Post by fnordpiglet »

v4dok wrote: post #23
vesinisa wrote: post #21

Earlier quoted context omitted.

The way I have understood FHE is that any algorithm that would operate on the data would, by definition, be unable to produce any result that was intelligible to anyone except the person holding the original key. At no point during the execution of an FHE algorithm is the data decrypted. The amazing thing is exactly that the code running on the data does not understand the data it is consuming nor the data that it is…

Thats true. But it will still produce some data, and that data will be viewed by someone eventually who owns the key to decrypt it. FHE tells you nothing about what this product should be. It could as well be a full copy of the original data. For example: I run an ML model using FHE on some data I shouldn't have access to in plaintext. The expected outcome of this workflow is a trained ML model on that data. FHE tell…

But the model itself is encrypted. You should assume a model trained on sensitive data at least partially includes the sensitive data and treat it as sensitive, as FHE intrinsically does. If you’re saying once you decrypt them model you need to keep treating it with sensitivity and not give it to untrusted compute in the plain, then yes you’re right. But that’s nothing to do with FHE because you stopped using FHE the moment you decrypted it. What stupidity you do after generations of PhD protected your data in untrusted compute using FHE is your stupidity alone and says nothing about FHE.

The other way I read what you’re saying you’re saying the holder of the model after they decrypt it may not be trusted with the model or the original data. But they hold the decryption key to both. So, why did you share the key to someone you don’t trust? That breaks the model too.

Re: The Rise of Fully Homomorphic Encryption

#89

Post by ricksunscreen »

foobiekr wrote: post #86
hinkley wrote: post #76

Earlier quoted context omitted.

Doesn’t fully homomorphic encryption have the Tux Image problem cited in block cypher discussions? With a symmetric cipher, I could figure out the blood type of every employee pretty easily. With an asymmetric cipher, I could figure out everyone who has my blood type, and the blood types of anyone who reveals that information. If the point is to filter data when you aren’t allowed to know what the data is, then the a…

I think you are thinking of how ECB ends up with the identical blocks having identical encrypted form due to key and IV reuse. I don't think this is a requirement for all forms of FHE.

In particular, most FHE schemes inherently add randomness to encryptions as an artifact of using Ring Learning with Errors (RLWE) for hardness. This means that Enc(pk, m) != Enc(pk, m) if you run the algorithm twice; each key and message pair can produce many different ciphertexts.

Re: The Rise of Fully Homomorphic Encryption

#90

Post by nominusllc »

carrotcypher wrote: post #38
m1ghtym0 wrote: post #19

> Today, conventional wisdom suggests that an additional performance acceleration of at least another 1 million times would be required to make FHE operate at commercially viable speeds. At the moment, Cornami is the only commercial chip company to announce a forthcoming product that can meet and exceed that performance level. Is there any comparison performance benchmark for these Cornami chips on real world algorit…

If no one answers here, might try on the FHE.org discord, loads of researchers there who probably wrote a paper on exactly that.

Any chance of an IRC or Matrix bridge?
Post reply on HN