Message passing in computers is flawed because messages can not be trusted

(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at:


First of all, if you call a random object to ask it a question of any kind, you can get a denial of service in the form of nontermination. This can be mitigated by using an asychronous send or resource limitation, in which case you may get no information about the object.

But it’s worse than this. Even if you ignore DOS and timeout, you
might think you could do challenge/response for authentication = “type check” or brand predication. Let’s see how this would work: You send a challenge, and get an object back that’s the response to the
challenge. Now how do you determine whether the response is the right response? Without identity, all you can possibly do is send a message to the response — and you’re faced with the problem you had before.

Even if you have identity, the solution is pretty gross — the two
ends of the authentication protocol would have to share the set (very
large) of potential response objects.

Well, maybe this can be fixed using encryption somehow. Remember that communication is a priori insecure because of things like

(lambda args
(spy-on! args)
(let ((result (apply target args)))
(spy-on! result)

So how do you do decryption under strong EiaO? After you receive the
encrypted result (another object, by EiaO), you have to send a message
to it – there’s nothing else you can do. So how do you know that
communication with the message itself is private? After all, you
received the encrypted message over an insecure channel, so a nasty
fake-encrypted-message might be substituted that spies on your attempt at decryption.