I just had Jeffrey over at MimeKit ask me a question, which went roughly like this; “Why do you choose to encrypt Web Service invocations, when SSL exists?”

The reason why he asked that question, was because I posted this video at his forums, asking what he thinks about my usage of his beautiful baby, AKA; MimeKit!

Here’s my pretty long answer to Jeffrey’s question;

Well, as you said, it’s easy to see the value of signing a message, since then you have a guarantee of that only the server with access to the private key created that message.

SSL on the other hand, as an alternative to PGP, is basically useless. The reason for that, can be summed up with five words; “Man In The Middle Attack”. If SSL was enough for encryption, then we wouldn’t have to encrypt our emails either, one can argue, since both POP3 and SMTP supports SSL and TLS. I realize that’s not entirely true though, since PGP encryption works from “end to end”, and the SMTP and POP3 server(s) might not necessarily be the final client reading the email, but it anyway shows my point, to some extent. However, keep on reading, the really good parts are below …

With PGP encrypted Web Services invocations, one can easily create what I like to refer to as the “Hammer Protocol”, which is basically the Onion Routing principles for Web Services. This allows me to create a Web Service invocation, sign and encrypt it for its final destination(s), then encrypt and sign it again for an intermediate destination, serving as my “Onion router”, and repeat this process 3-5 times. Then pass on my message to the destination I signed and encrypted my message to the last time. When that destination receives my message, it will decrypt it, wait for a random amount of time, before it re-transmits the results of that decryption operation to the destination found inside the encrypted original outer message. This decrypted message is still an encrypted message though, but everything in it is different, since unwrapping the original encrypted message produced a “completely different message signature”.

With the above scenario, I could have a Web Service invocation, using the Hammer/Onion (think Tor) routing principles to completely hide who is communicating with who, how many other server end-points the server is communicating with, and basically render all intelligence operations completely useless.

Trying to map out which parts of the networks talks with which other parts, would become literally impossible! All servers that are “friends” with other servers, and how many “friends” one server has, would be hidden behind a completely opaque cloud of PGP, Encryption, PGP Signatures, Onion routing and Triple/Quadruple/Quintuple wrapped encrypted MIME messages.

My server could send out a tiny small HTTP request to another server, which again re-transmits that message to 100 other servers, over a time period of 5 hours, where each recipient of that message re-transmits the message again to 100 more servers, again with a time delay. This way, I am able to transmit a message to 10.000 servers, and any surveillance attempts, trying to figure out with where the message came from, will be impossible, and apparently my little server was just sending one message, to one server, and hence cannot in any ways be a suspect in regards to where this message originated.

If you like seeing in analogies, then think of the web as a Holistic Brain, where each individual neuron is just a part of a larger whole, having oneness emerge as a naturalistic principle. Just like one individual neuron in your brain has no idea why or what it is firing, when it is firing, one individual server in this network, would have absolutely no idea what it is transmitting, and to whom it is transmitting it to.

The final point about encryption, is difficult to understand without understanding a couple of USPs about Hyperlisp and pf.lambda, which is a “programming language” I realized as a consequence of inadequate abilities to “orchestrate code” and pieces of logic together with “data”. Hyperlisp can be perceived as a “better JSON”, and is a key/value/children tree node-structure, with the capability to transmit type-information for individual values. Think about it like another version of BSON (Binary JSON). But Hyperlisp is much easier to “read” for humans.

Hyperlisp again, translates perfectly to “pf.lambda”, which is an “execution structure” for computers, with some pretty unique abilities. To completely explain pf.lambda, would require much more space than I’ve got room for here, but to sum it up, such that you understand the main USP in regards to encryption, realize that I can create a piece of Hyperlisp “excutable piece of code”, then sign it, encrypt it, for then to transmit it to another server. This other server could then store that piece of “code”, and use it to invoke Web Services other places. This allows me to serialize and transmit pieces of “code” to other parties, where the party receiving my code, has absolutely no idea what the code does, and this code could include passwords to a database for that matter. Then every time the other party wish to use this code, it might transmit it to a third party, and then have that third party execute that piece of code, after verifying the signature, and decrypting the message, and return the results back to the server that invoked that Web Service.

With the above scenario, I can create a “serialized callback invocation” for another server, that can be invoked any time the other party needs to invoke it, to retrieve some piece of data, either from my server, or a third party server. And this “code” could contain proprietary logic, secret keys and passwords, in addition to other publicly available parameters, serialized in other parts of the MIME message. Then the whole message could be signed and encrypted, before passed onwards to the node that executes it. With this, I can have this piece of Hyperlisp, which I know that if I transmit it to “weather-data.com”, adding a “begin” and “end” date in another MIME entity, will return the weather results for the period I requested. Since this encrypted code, is signed by an authority that “weather-data.com” trusts, the servers at “weather-data.com” can execute this code, trusting that it won’t explode their servers, or send their root password to “Cosa Nostra”

The above scenario, is why it is so important for me that MIME is a “tree structure”, as you say on your front-page here at GitHub, because with that tree-structure, I can double-encrypt, triple-encrypt, and serialize encrypted MIME messages on disc, only to allow a specific party to decrypt it, when the time comes for this decryption process to happen. While at the same time, sign my invocations, at all levels, allowing for the receiver of my message to have a 100% bullet proof guarantee of that the message originated from me!

To quote Alan Kay; “Think in terms of Biology, and not in terms of Computers. Then it all makes sense”

Now over to something completely unrelated 😀

For the record, the code I am showing in the first video above, is still not yet released …