Spiral’s Homomorphic Encryption – Is This the Future of Privacy?
21analytics.ch
21analytics.ch
I like this article's crypto wallet use case, and it may be worth codifying transactions that FHE protects. The {who, what, when, where, why, how} of a transaction has a lot of data, and what this SpiralDB does is protect {what}, although {who, when, where, why, how} are available, so you need to articulate the use case.
The one I worked on was for health information, but that case is essentially nullified now, as the pandemic was leveraged to squeeze the data toothpaste out of the tube in major jurisdictions, and so the data sets FHE was going to be a big solution for have been accessed using a political/process solution without the limitations of a technical one. The main use case for FHE was to faciliate individual privacy, which is essentially a limit on state discretion and powers that facilitated data access through strict legal frameworks, but a lot of data governance was completely compromised and gutted over the pandemic, so I no longer foresee demand for FHE in this new era of aggressively technocratic policy where the reason to use FHE isn't enforced. The tech is inseperable from the policy in this domain, and the rug has been pulled out from under the policy, imo.
Can you provide more information for those of us who are interested in the intersection of health and data privacy but don't work in the space?
Personally, I think highly regulated fields like health care etc will adopt this technology extremely slowly. Academic cryptographers really like health care applications but, as you said, in practice, compliance is the main objective of health care organizations.
We are more interested in applications where privacy is actually a value add or a liability minimizer. For example, a VPN using our service could differentiate or charge more to users for offering a completely private DNS option. A crypto wallet could actually advertise (and perhaps even prefer!) that it doesn't spy on you.
As of now, a lot of privacy is lost when you actually look at Nostr events. There are servers that check to see if a user has paid before they execute the request too[2].
Not true in general, since you can reuse the multiplexor multiple times during the evaluation, to produce essentially a circuit-wise least-common-multiple of the two sides of the branch. Eg, if one side performs two multiplications, and the other a multiplication and a division, you only need to evaluate a division and two multiplications, not a division and three multiplications. So "evaluate both sides" is a worst-case upper bound on the amount of computation.
Loops are still a pain in the ass, though.
The Wikipedia demo[1] starts with a big download because you're fetching an index of articles. Subsequent requests have you send an encrypted one-hot[2] vector making the article you want to read. The server does an encrypted dot-product of the vector with the vector of articles, returning just the encrypted article you're looking for.
A messaging system could do the same thing, where your vector selects member identifiers or public keys.
Spiral has a video[1] where they dive into some of the details.
We never built it into a product because we couldn't figure out a way to monetize it to pay for the servers.
To quote an ex-NSA chief "We kill people based on metadata". https://abcnews.go.com/blogs/headlines/2014/05/ex-nsa-chief-...
Metadata is data.
One big obstacle with E2EE, though, is that it relies on clients to do basically all of the computations. But, among other things, there are situations where you might imagine wanting to be able to allow an operation to be completed without needing both clients to actively participate, without revealing key matter directly.
Examples of FHE seem to stick to fairly simple things, but a lot of the more modern demos show off more interesting capabilities. What I wonder is, what is practical today using today's stacks? For example, could a server blindly perform cryptographic operations under the veil of FHE, potentially using parameters from multiple parties?
It seems like, if FHE proves to be robust and sufficiently secure, it has a lot of potential, and I really wonder what can be done with it today. I've made some effort to explore, but not being an academic a lot of it has been pretty difficult to grok.
We're currently building a service that will let you do private lookups without needing to really mess with the underlying cryptography or schemes. You'll be able to use it to deliver even stronger privacy than E2EE ("E2EE+"?). For example, DNS that doesn't learn what you resolve (this is beyond something like DNS-over-HTTPS), or a messaging service that doesn't learn who you talk to.
As far as learning more, I wrote a blog post that tries to cover the basics of doing private lookups: https://blintzbase.com/posts/pir-and-fhe-from-scratch/.
I'm very interested in FHE in the context of machine learning models without requiring access to unencrypted data at any stage (be that training or inference). So far, the performance hit wouldn't make this practical, so I was wondering whether maybe hardware solutions exist to deal with that.
FHE for ML is indeed not super practical yet. There are some recent works that get quite close: CryptGPU (https://arxiv.org/pdf/2104.10949.pdf) and Piranha (https://www.usenix.org/system/files/sec22-watson.pdf) both leverage GPU's for private ML (and even some MPC!).
As a rule of thumb, HE allows you to offload a intensive computation (or one that requires a private model) to a server that you don't trust. Only you can decrypt the results. DP, on the other hand, lets the server analyze big data and use the results. Privacy is achieved by each input being "noisy", so no little information is leaked. The statistics still work because over a large data set the noises cancel out.
31 Nov, 2022”
For now, it seems to be. LOL
The underlying cryptosystems are often LWE (Learning with Errors), RLWE (Ring Learning with Errors) and one called (R)GSW (named after the authors of this paper: https://eprint.iacr.org/2013/340) which is also based on (R)LWE.