(There are real applications, particularly in privacy preserving financial cryptography. But the database application is just a BS non-niche justification for grant purposes.)
What client would want to add some numbers without knowing what the result is?
I can't imagine any interaction with a database where I don't need to do an operation with the resulting data (even if it's just passing it into a different API/DB unchanged).
My interpretation of your example in human terms is "add your day of birth to your bank balance, but don't tell me the answer" and then walking away. What am I missing?
-- edit --
Maybe I'm looking at it in the wrong direction? Is it more like "here are some numbers that, add them up on your calculator but don't look at the result before showing it to me"?
That is essentially what zcash is. So as I said, numerous applications in financial crypto (where we can reasonably spend full seconds on desktop, or minutes on secure hardware grinding away at proof to send funds), but not so practical to spend an even greater amount of time on each database query.
for element of listB:
listA.add(element)
listA.sort()
listA.sort()
for element of listB:
listA.insertInSortedPosition(element)
I mean, yeah, sometimes you can. And in that case, "premature optimization is the root of all evil," sure. If you're just pulling a couple hundred product records out of a database and then sorting them in code, then yeah, an O(N log N) sort is "basically a free operation."
But sometimes you want to do more complicated things than that, and then it's not true. So overall I think it's pretty irresponsible to teach that sorting is basically free (without caveats). That's definitely not always true!
Hash tables and trees are O(1) or O(lg N) which are vastly faster than O(N).
Imagine a database with billions of records. O(N) search on this database will absolutely murder performance.
Does homomorphic encryption allow running operations blindly on an encrypted dataset and return encrypted results without ever decrypting the dataset?
Why do you think HE value map cannot be ever improved?
These applications can easily handle an 80 sec delay. It's also likely that queries scale well by batching into larger combined queries (since you need to involve every row already anyway).
1. Alice provides Bob with her public and evaluation keys.
2. Bob encrypts each row of the blacklist with her public key.
3. Alice encrypts her query (e.g. for "Eve") and sends to Bob.
4. Bob evaluates some circuit on Alice's query and Bob's rows, and sends her one (encrypted) result per row
5. Alice decrypts the rows and sees if any are ones.
Ways this can be made more efficient:
* Outputs from each row's evaluation can chain into the next evaluation, so Bob only need return O(1) data.
* Bloom filters could cut down on average-case performance, but that would make Alice leak information (whether she follows up her FHE bloom filter query with a more precise query.)