This would allow a client to combine a server-provided function that calculates a spam score with their private key such that the resulting function calculates a spam score on encrypted email. The client could then hand that function back to the server so it can perform server-side spam detection.
There are a number of drawbacks, including performance and general questions about the security of such a system. That said, I think this is probably the biggest problem (from the OP):
"The third problem is that spam filters rely quite heavily on security through obscurity, because it works well. Though some features are well known (sending IP, links) there are many others, and those are secret. If calculation was pushed to the client then spammers could see exactly what they had to randomise and the cross-propagation of reputations wouldn't work as well."
Using functional encryption to provide server-side spam detection would still require handing a spam scoring function to the client so they can apply that function to their private key and hand the server a result. This would expose the internals of the spam detection routine to all clients, including spammers.
The problem with functional encryption is as you say, you need to hand over the "function" somehow to the server (presumably they use machine learning and tools that aren't feasible client-side), and there's no guarantee the private key is hidden unless you use something like indistinguishibility obfuscation, which isn't really practical at all right now.
Did you mean fully homomorphic encryption? (https://en.wikipedia.org/wiki/Homomorphic_encryption#Fully_h...) The server can compute the spam score under the encryption of an email, and client side decrypts and sorts it from there, so not even the server knows if a given email is spam or not. Of course, not that FHE is feasible, but perhaps this special case is...
No, I didn't mean FHE, because FHE does not meet the criteria given in the post, namely that it must happen as quickly as possible and cannot rely on the liveness of the client. The OP practically rules out schemes that involve looping in the client.
What? With FHE the client just gets an additional encrypted metadata that is the encryption of whether the attached file is spam or not. No looping required, whereas your functional encryption scheme seems to necessitate the client being "live."
One of the requirements given in the OP (the one I was referencing in my previous post) is that the server can tell spam from non-spam without the client being online. The FHE solution doesn't work for this requirement.
The functional encryption scheme only requires a client to bootstrap it. Once the client has calculated the appropriate function based on their private key, they can give it to the server, who can thereafter apply it to incoming emails regardless of whether the client is online or offline.
Okay so to fix mine: create a circuit that decrypts a ciphertext using the private key, returning 1, 0, or Bottom depending if it's an encryption of spam marking or not, or not valid, and run it through iO. So both solutions still require iO...
Also, in order to build the function, the service needs to collect data about both spam and non-spam emails. So simply providing a function that allows you to calculate a score isn't enough; they would need (at least a large percentage of) users to send back information about their email contents as well. (Like embedded links, as mentioned in the post.)
https://en.wikipedia.org/wiki/Functional_encryption
This would allow a client to combine a server-provided function that calculates a spam score with their private key such that the resulting function calculates a spam score on encrypted email. The client could then hand that function back to the server so it can perform server-side spam detection.
There are a number of drawbacks, including performance and general questions about the security of such a system. That said, I think this is probably the biggest problem (from the OP):
"The third problem is that spam filters rely quite heavily on security through obscurity, because it works well. Though some features are well known (sending IP, links) there are many others, and those are secret. If calculation was pushed to the client then spammers could see exactly what they had to randomise and the cross-propagation of reputations wouldn't work as well."
Using functional encryption to provide server-side spam detection would still require handing a spam scoring function to the client so they can apply that function to their private key and hand the server a result. This would expose the internals of the spam detection routine to all clients, including spammers.
A difficult tradeoff.