61–70 of 202 posts
It's idealistic to think this could solve data braches because businesses knowing who their customers are is such a fundamental concept.
I think the opening example involving Google is misleading. When I hear "Google" I think "search the web". The articles is about getting an input encrypted with key k, processing it without decrypting it, and sending back an output that is encrypted with key k, too. Now it looks to me that the whole input must be encrypted with key k. But in the search example, the inputs include a query (which could be encrypted wit…
Consider the following (very weak) encryption scheme:
m, k ∈ Z[p], E(m) = m * k mod p, D(c) = c * k⁻¹ mod p
With this, I can implement a service that receives two cyphertexts and computes their encrypted sum, without knowledge of the key k:
E(x) + E(y) = x * k + y * k mod p = (x + y) * k mod p = E(x + y)
Of course, such a service is not too interesting, but if you could devise an algebraic structure that supported sufficiently complex operations on cyphertexts (and with a stronger encryption), then by composing these operations one could implement arbitrarily complex computations.
So unless Google lets me encrypt their entire search index, they can still see my query at the time it interacts with the index, or else they cannot fulfill it.
The other point is incentives: outside of some very few, high-trust high-stakes applications, I don't see why companies would go through the trouble and FHE services.
Earlier quoted context omitted.
You're not joking. If you're like most people and have only a few TiB of data in total, self hosting on a NAS or spare PC is very viable. There are even products for non-technical people to set this up (e.g. software bundled with a NAS). The main barrier is having an ISP with a sufficient level of service.
Sure, hardware is cheap. However if you actually follow the 3-2-1 rule with your backups, then you need to include a piece of real estate in your calculation as well, which ain’t cheap.
FHE might allow arbitrary computation, but I use most services because they have some data I want to use: their search index, their knowledge, their database of chemicals, my bank account transactions, whatever. So unless Google lets me encrypt their entire search index, they can still see my query at the time it interacts with the index, or else they cannot fulfill it. The other point is incentives: outside of some…
I think the opening example involving Google is misleading. When I hear "Google" I think "search the web". The articles is about getting an input encrypted with key k, processing it without decrypting it, and sending back an output that is encrypted with key k, too. Now it looks to me that the whole input must be encrypted with key k. But in the search example, the inputs include a query (which could be encrypted wit…
> Now it looks to me that the whole input must be encrypted with key k. But in the search example, the inputs include a query […] and a multi-terabyte database […] That’s not the understanding I got from Apple’s CallerID example[0][1]. They don’t seem to be making an encrypted copy of their entire database for each user. [0]: https://machinelearning.apple.com/research/homomorphic-encry... [1]: https://machinelearning…
Moreover, even if the details were slightly different, a scheme that reveals absolutely no information about the query while interacting with a database always needs to do a full scan. If some parts remain unread depending on the query, this tells you what the query wasn't. If you're okay with revealing some information, you can also hash the query and take a short prefix of the hash with many colliders, then only scan values with the same hash prefix. This is how browsers typically do safe browsing lookups, but by downloading that subset of the database instead of doing the comparison homomorphically on the server.
> Internet's "Spy by default" can become "Privacy by default". I've been building and promoting digital signatures for years. Its bad for people and market-dynamics to have Hacker News or Facebook be the grand arbiter of everyone's identity in a community. Yet here we are because its just that much simpler to build and use it this way, which gets them more users and money which snowballs until alternatives dont matte…
> that works well enough that very few use cases want the complexity cost FHE + AI might be the killer combination, the latter sharing the complexity burden.
Earlier quoted context omitted.
https://sgx.fail
I think SGX (et al) can still be useful as part of a layered defense. We know how to defeat security mitigations like NX and ASLR, but that doesn't mean they're useless. The problem is that SGX is marketed as the solution.
I think the opening example involving Google is misleading. When I hear "Google" I think "search the web". The articles is about getting an input encrypted with key k, processing it without decrypting it, and sending back an output that is encrypted with key k, too. Now it looks to me that the whole input must be encrypted with key k. But in the search example, the inputs include a query (which could be encrypted wit…
Homomorphically encrypted services don't need a priori knowledge of the encryption key. That's literally the whole point. Consider the following (very weak) encryption scheme: m, k ∈ Z[p], E(m) = m * k mod p, D(c) = c * k⁻¹ mod p With this, I can implement a service that receives two cyphertexts and computes their encrypted sum, without knowledge of the key k: E(x) + E(y) = x * k + y * k mod p = (x + y) * k mod p = E…
Earlier quoted context omitted.
> that works well enough that very few use cases want the complexity cost FHE + AI might be the killer combination, the latter sharing the complexity burden.
Is there any reason to think this is a meaningful combination, or do you just like saying the word AI?
Searching Google query by query as one prosecutes a question with FHE would be annoying. Asking an on-device LLM to go back and forth with Google using FHE is not. I'm also assuming that FHE won't cover all operations, and that its coverage would be both constantly changing and well documented, which is another place where an LLM could abstract away smoothly failing back from FHE to open querying.
Put another way, AIs' text-first prompt-oriented UI seems to be a good fit for FHE in a way that e.g. a dashboard is not.