This is called secure, multi-party computation. Secure computation, which can be just one party, would take a lot longer to explain. It's also a prerequisite for secure, multi-party computation as attacks on the host can bypass the multi-party protocol. That's why you'll always see me mock those that think such schemes will let us ignore INFOSEC problems. They're fun to read, though.
Lol if you think cryptography doesn't consider corruptions of involved parties; there's a huge host of studied corruption models, from static to adaptive corruption, and different type of corruptions, from malicious to rational to covert adversaries.
Secure computation is a catch-all term for cryptographically safe computation; this includes ORAM schemes, FHE, iO, Searchable Symmetric Encryption, PIR, etc.
If you mock without knowing, you're the fool. No one claims that these schemes can solve computer security problems; for one, these schemes are still largely theoretical. But there's been huge advances in the field, and some things that have emerged as a result of this theory are being deployed by Google, Microsoft, etc (CryptDB).
"Secure computation is a catch-all term for cryptographically safe computation; this includes ORAM schemes, FHE, iO, Searchable Symmetric Encryption, PIR, etc."
I'm aware that they have all kinds of interesting models. I even have papers on a few of those. I'm also aware cryptographers often ignored concrete details of their ideas in ways that led to real-world vulnerabilities. This happened with padding, covert channels, implementation difficulties, and so on.
"If you mock without knowing, you're the fool."
I said it's called Secure, Multiparty Computation in most discussions of this stuff if it's crypto letting two or more work together on something often with confidentiality but sometimes just integrity. That was the label where I first saw it in Schneier's book all the way up to an article I saw after this one. Are you saying the concept is not called multiparty computation?
Or are you saying that anyone publishing cryptographic papers has factored into their math assumptions and effects of host CPU's, caches, interrupts, I/O, compilers, networks, and users? That would be a mock-worthy claim. Those ground in practical reality and useful are rare enough that I post them on Schneier's blog and here to bring attention to them. Incidentally, ORAM and CryptDB were among those I posted worth exploring for potential, real-world benefit. ;)
Note: I did critique CryptDB as not good enough against NSA as some media portrayed it. It relies on underlying host, software running on it, and distribution of both. NSA has been smashing such things. So, if A then B, the dependency shows it's insecure against such a High Strength Attacker. Good for many others and still potential here, though.
