It might indeed be possible to construct a (homœomorphic-encryption-based? Some curve with pairings? Some form of encrypted Bloom filter in a tree?) indexed storage that an untrusted service can store and only a trusted client with a key can search or access. (How practical that is, and what the service can learn from access pattern metadata, is another question entirely. Frontloading onto clients may actually be more amenable in practice.)
Key handling is primarily a UX problem (and a big one), but is also not insoluble, or at least, not harder than bloody passwords.
It may be tricky, but I am not entriely convinced it is impossible.
However, to address the grandparents' point: Lavabit provides some evidence that US authorities perhaps can compel an uncooperative provider in this scenario to backdoor their software, allow their service to be impersonated, or some other facilitation if they cannot access contents in a service as designed - at the very least, if it is not already available, there are legislative and pre-legislative pushes in the US and UK for that capability to be made available to nation-state adversaries in the future, although it's unclear if that'll come to fruition - hopefully not, but get ready for a fight on that in the future. (iOS-related correspondence from FBI; the so-called "snoopers' charter" over here.)
Let me point out the key line of my comment: And I don't want to bother handling my own encryption keys.
The proof is quite simple. If I don't have my own keys I have no information the NSA lacks. Thus, they can only access the same information I can.
Homomorphic encryption would theoretically allow google to do encrypted indexing, but I still need to handle my keys to construct the query. It's also mainly theoretical at this point, though I am eager to see it built for real.
There's no reason that handling your own keys has to be something that you, personally, have to bother with. Just because you don't interact with the key handling doesn't mean it can't happen in a safe and secure environment on your local machine.
Yes there are plenty of implementation concerns, but that doesn't mean they're insurmountable. It's so possible, in fact, that ongoing work is happening in exactly this space. See https://code.google.com/p/end-to-end/ for example.
It might indeed be possible to construct a (homœomorphic-encryption-based? Some curve with pairings? Some form of encrypted Bloom filter in a tree?) indexed storage that an untrusted service can store and only a trusted client with a key can search or access. (How practical that is, and what the service can learn from access pattern metadata, is another question entirely. Frontloading onto clients may actually be more amenable in practice.)
Key handling is primarily a UX problem (and a big one), but is also not insoluble, or at least, not harder than bloody passwords.
It may be tricky, but I am not entriely convinced it is impossible.
However, to address the grandparents' point: Lavabit provides some evidence that US authorities perhaps can compel an uncooperative provider in this scenario to backdoor their software, allow their service to be impersonated, or some other facilitation if they cannot access contents in a service as designed - at the very least, if it is not already available, there are legislative and pre-legislative pushes in the US and UK for that capability to be made available to nation-state adversaries in the future, although it's unclear if that'll come to fruition - hopefully not, but get ready for a fight on that in the future. (iOS-related correspondence from FBI; the so-called "snoopers' charter" over here.)