Fully homomorphic encryption doesn't provide an ability to operate on encrypted data and get a decrypted output. It is also absurdly slow, with order-of-magnitude performance of a minute per and-gate in the operation being performed.
But, lets forget the terms you used and consider the question of "can fancy crypto do something here"?
A protocol could be created using a zero knowledge proof and a private set intersection that could do the following: I compute the hash of a file, blind it, and then submit it for you to query against a secret database of naughty hashes (Private set intersection / Private information retrieval). Then I encrypt the file, send it, the opened intersection result, and a ZKP that the encrypted file has a hash corresponding to the query.
The server only learns if the encrypted file was a hit on your database, it doesn't even learn the file's hash if it wasn't a hit. If the private intersection scheme is setup right the user doesn't learn if it was a hit or not.
Assuming the naughty hash databases was reasonably small (like tens of thousands of items), and users were assumed to be on very fast smart phones or desktops... then could actually this could have workable performance with existing tech-- on the order of tens of seconds processing on the client, milliseconds on the server.
But, this kind of scheme is pointless: I just make a one bit change to every file I send and it'll never match. You could invoke some kind of fuzzy match but then false positives are a real problem, the fuzzy hashing is a lot more expensive to perform inside the ZKP (now you need every user on a 8 core desktop), and the fuzzy matching is prohibitively expensive inside the private intersection (so the server side scales poorly).
You could go further and make it so that the server could decrypt the entire file if and only if there was a fuzzy match (and still, the user still can't tell if a match happened)-- but even that would create really bad incentives to stuff the database with false-positive producing data (or just loads of legally protected speech which they'd like to covertly monitor). You couldn't make the database public and transparent without distributing the naughty-data yourself and without making it easy for users to self-censor anything that might match.
... and that kind of supercharged scheme is also still easily defeated by just pre-encrypting the data.
So you'd have a system that was absurdly expensive to create, expensive to operate (both for the client and server), extremely non-transparent due to its complexity (even if it was open source) and private database, and would have extremely limited ability to do its job. Users would be subjected to an uncertain and non-transparent level of non-privacy. To me that seems more dystopian than a transparent "we're gonna watch everything you do", at least with a simple surveillance state you know where you stand and you'll refrain from complaining about Dear Leader online, where it might result in you ending up in a prison camp.
The whole discussion misses the point that the real goal of these systems isn't to protect children, stop child porn, etc. (which, as awful as it is, is essentially a rounding error in the risks we face) the real purpose it to subject the population to pervasive whole-take retroactively accessible surveillance.
But, lets forget the terms you used and consider the question of "can fancy crypto do something here"?
A protocol could be created using a zero knowledge proof and a private set intersection that could do the following: I compute the hash of a file, blind it, and then submit it for you to query against a secret database of naughty hashes (Private set intersection / Private information retrieval). Then I encrypt the file, send it, the opened intersection result, and a ZKP that the encrypted file has a hash corresponding to the query.
The server only learns if the encrypted file was a hit on your database, it doesn't even learn the file's hash if it wasn't a hit. If the private intersection scheme is setup right the user doesn't learn if it was a hit or not.
Assuming the naughty hash databases was reasonably small (like tens of thousands of items), and users were assumed to be on very fast smart phones or desktops... then could actually this could have workable performance with existing tech-- on the order of tens of seconds processing on the client, milliseconds on the server.
But, this kind of scheme is pointless: I just make a one bit change to every file I send and it'll never match. You could invoke some kind of fuzzy match but then false positives are a real problem, the fuzzy hashing is a lot more expensive to perform inside the ZKP (now you need every user on a 8 core desktop), and the fuzzy matching is prohibitively expensive inside the private intersection (so the server side scales poorly).
You could go further and make it so that the server could decrypt the entire file if and only if there was a fuzzy match (and still, the user still can't tell if a match happened)-- but even that would create really bad incentives to stuff the database with false-positive producing data (or just loads of legally protected speech which they'd like to covertly monitor). You couldn't make the database public and transparent without distributing the naughty-data yourself and without making it easy for users to self-censor anything that might match.
... and that kind of supercharged scheme is also still easily defeated by just pre-encrypting the data.
So you'd have a system that was absurdly expensive to create, expensive to operate (both for the client and server), extremely non-transparent due to its complexity (even if it was open source) and private database, and would have extremely limited ability to do its job. Users would be subjected to an uncertain and non-transparent level of non-privacy. To me that seems more dystopian than a transparent "we're gonna watch everything you do", at least with a simple surveillance state you know where you stand and you'll refrain from complaining about Dear Leader online, where it might result in you ending up in a prison camp.
The whole discussion misses the point that the real goal of these systems isn't to protect children, stop child porn, etc. (which, as awful as it is, is essentially a rounding error in the risks we face) the real purpose it to subject the population to pervasive whole-take retroactively accessible surveillance.