You're right. This isn't a good use case for FHE. Instead, FHE is really useful when the query itself is private, and the data is not private. One example is a

You're right. This isn't a good use case for FHE. Instead, FHE is really useful when the query itself is private, and the data is not private. One example is a private OCSP. Every time you open a TLS-secured webpage, your browser has to check whether or not the TLS certificate has been revoked (I'm leaving out some complications but bear with me). In order to do that, you browser has to contact the certificate authority (CA) and ask "has anyone revoked this cert?". But in doing that, the browser is revealing your browsing patterns to the CA! It would be nice, instead, to use Private Information Retrieval to ask the CA "please process this encrypted query and return the result". Then the CA knows nothing about your browsing patterns, and you still get your data. Well, (computational) Private Information Retrieval is super inefficient today, and the best asymptotic solution we have is based on FHE (https://eprint.iacr.org/2017/1142 https://eprint.iacr.org/2017/1142). So getting efficient FHE would hopefully make something like this a lot more reasonable for moderately sized databases. For the record, this is only a toy example. We actually have really good solutions for private OCSP that don't require FHE. We can side-step the difficult of Private Information Retrieval in this case because OCSP databases are small enough for anyone to download. If this interests you, check out CRLite https://blog.mozilla.org/security/2020/01/09/crlite-part-1-all-web-pki-revocations-compressed/ https://blog.mozilla.org/security/2020/01/09/crlite-part-1-a...