I was surprised that for almost 300 pages there were only 26 references listed in the back. Not the end of the world by any means, clearly a ton of work went into this, but I find it useful to see from references how it overlaps with other subjects I may know more about
The Beginner's Textbook for Fully Homomorphic Encryption
31–40 of 51 posts
Re: The Beginner's Textbook for Fully Homomorphic Encryption
#32FWIW: I created a github repo for compact zero-knowledge proofs that could be useful for privacy-preserving ML models of reasonable size (https://github.com/logannye/space-efficient-zero-knowledge-p...). Unfortunately, FHE's computational overhead is still prohibitive for running ML workloads except on very small models. Hoping to help make ZKML a little more practical.
Re: The Beginner's Textbook for Fully Homomorphic Encryption
#33I was under the impression that, for any FHE scheme with "good" security, (a) there was a finite and not very large limit to the number of operations you could do on encrypted data before the result became undecryptable, and (b) each operation on the encrypted side was a lot more expensive than the corresponding operation on plaintext numbers or whatever. Am I wrong? I freely admit I don't know how it's supposed to w…
the goalpost moved and it's not private anymore, just private enough.
Re: The Beginner's Textbook for Fully Homomorphic Encryption
#34I was under the impression that, for any FHE scheme with "good" security, (a) there was a finite and not very large limit to the number of operations you could do on encrypted data before the result became undecryptable, and (b) each operation on the encrypted side was a lot more expensive than the corresponding operation on plaintext numbers or whatever. Am I wrong? I freely admit I don't know how it's supposed to w…
the goalpost moved and it's not private anymore, just private enough.
[dead]
Re: The Beginner's Textbook for Fully Homomorphic Encryption
#35Earlier quoted context omitted.
Oh. It really is that bad still. So if the question is between wrapping the plaintext in layers of security, or building out a million new server instances to do it via FHE, i know which one everyone will choose.
It is not that bad these days, closer to 10,000x. Accelerators are being developed that claim to get down to 10x, though i think they will be more like 100-1000x, which would still be a huge improvement considering how people use LLMs today for basic tasks like string matching.
Are those accelerators software-only? 10x could let 4$ VPS run server side checks for backup software (evil clients cant clean backups) and git forges (eg, dont allow X to push to main).
Re: The Beginner's Textbook for Fully Homomorphic Encryption
#36What is the computational burden of FHE over doing the same operation in plaintext? I realize that many cloud proponants think that FHE may allow them to work with data without security worries (if it is all encrypted, and we dont have the keys, it aint our problem) but if FHE requires a 100x or 1000x increase in processor capacity then i am not sure it will be practical at scale.
It's really not that bad. We're close to using FHE in a production consumer app. https://vishakh.blog/2025/08/06/lessons-from-using-fhe-to-bu...
if you're talking about doing database queries on a 5mb database, why not just ship the database client side and have them do the computation?
Re: The Beginner's Textbook for Fully Homomorphic Encryption
#37FWIW: I created a github repo for compact zero-knowledge proofs that could be useful for privacy-preserving ML models of reasonable size ( https://github.com/logannye/space-efficient-zero-knowledge-p... ). Unfortunately, FHE's computational overhead is still prohibitive for running ML workloads except on very small models. Hoping to help make ZKML a little more practical.
This sounds super interesting. Can you elaborate on how you apply ZK to ML? (or can you point me to any resources?)
Re: The Beginner's Textbook for Fully Homomorphic Encryption
#38Funny thing is Since neural networks are differentiable, they can be homomorphically encrypted! That’s right, your LLM can be made to secretly produce stuff hehe
Differentiability isn’t a requirement for homomorphism I don’t think. Homomorphism just means say I have a bijective function [1] f: A -> B and a binary operator * in A and *’ in B, f is homomorphic if f(a1*a2) = f(a1)*’f(a2). Loosely speaking it “preserves structure”. So if f is my encryption then I can do *’ outside the encryption and I know because f is homomorphic that the result is identical to doing * inside th…
[deleted]
Re: The Beginner's Textbook for Fully Homomorphic Encryption
#39FWIW: I created a github repo for compact zero-knowledge proofs that could be useful for privacy-preserving ML models of reasonable size ( https://github.com/logannye/space-efficient-zero-knowledge-p... ). Unfortunately, FHE's computational overhead is still prohibitive for running ML workloads except on very small models. Hoping to help make ZKML a little more practical.
Did you check Zama.ai's work on FHE?
Re: The Beginner's Textbook for Fully Homomorphic Encryption
#40Let's admit for a second that the problem around computational cost is solved and using FHE is similar to using plaintext data.
My question might be very naive but I'd like to better understand the impact of FHE, discussions here seem to revolve very much around the use of FHE in ML, but are there other uses for FHE?
For example, could it be used for everyday work in an OS or a messaging app?
Also, is it the path for true obsfuscation?