How Your Business Can Stay Your Business in the Digital World

"Cryptology is the science of secret communication," explains David Chaum in his 1981 publication, Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms. Although cryptology has been around for thousands of years, protecting our physical or spoken information (think coded radio transmissions from The Imitation Game or ancient ciphers used in The Da Vinci Code), this same level of privacy hasn't always been available to users of the internet.

These old methods relied on a type of cryptology known as symmetrical encryption. This required both parties to have a previously determined cipher that could be used to both lock and unlock a message like a traditional key.

The early internet did not have access to such methods because of two main issues:

1. The key distribution problem: Basically, if I could use a code to distort my secret message (encryption), how can I give the recipient the key to unlock this?
2. The traffic analysis problem: If we are all using the same network to transmit information, can't anyone listen in? Yes.

In the early era of the internet, this privacy was limited to the government and military operations because they had the resources to secretively distribute ciphers and also use private traffic subnets. The average user in this time was not so resourceful, and as such was out of luck.

Public-Key Encryption

In the mid-1970s a few Stanford mathematicians, Diffie and Hellman solved the key distribution problem with public-key encryption. They theorized a system in which every user is able to create two keys, K and K^-1, where K is a public key known to everyone and K^-1 is your private key known only to you. These keys are inverses of each other in the sense that anything encrypted by K could be un-encrypted by K^-1 and vice-versa such that for any message m:

K-1(K(m)) = K(K-1(m))

Following this logic user, Y and X could send secret messages to each other. X would compose a secret message m, using Y's public key, so that only Y would be able to unlock m with their private key. In order to ensure that this message was untampered with, X could digitally sign m before it was encrypted with Ys public key. X digitally signs m with its own private key so that it can only be unlocked with its public key. Since X is the only person who has their private key, only they could have signed it. This message will look like this:

Ky(Kx-1(m))

What you should take away from this is you encrypt with their public key so only they can unlock the message, and you sign with your private key so that they can use your public key to verify only you could have signed it.

Sending Anonymous Messages

Now that we have the basis of public-key encryption at our disposal we can use it to send private messages to another person. We can do so even on a public network where anyone could see your traffic. How then could I hide who I am talking to, when, and even who I am? This is the crux of the traffic analysis problem and is a bit more complicated to solve.

First, let's walk through how we would use public-key encryption to get a secret anonymous message to another person.

Digital Pseudonyms make it possible to maintain a completely anonymous presence online. This has never been more relevant with the creation of the metaverse and other online platforms. Identity no longer needs to be tied to reality. From a key-pair perspective, a digital pseudonym is nothing more than a public key used to verify a signature made by an anonymous holder of the private key. So for example, instead of using my public key associated with my GitHub profile, I could create another one associated with an anonymous user online.

If I use a public key that reveals nothing about myself I should be good to send an anonymous message, right? Not quite. If you are sending a message to a person it will need to travel over a network. The network is made up of at least one server that will need to process the request and forward it to the correct address. This server, which we will call a mix, knows where the message came from and where it went to. Anyone listening in at that point would also know that message was sent from point A to B through the mix. This person might not know what the message contained, but they know the path, the number of messages sent the relative size of each message and the time at which these were sent.

To obfuscate the metadata about this interaction, one can employ a few techniques. The first is known as cascading: a method for passing a message through a series of predetermined mixes. This is accomplished by wrapping your message in levels of encryption which only the following mix has the key to open.  To pass through two mixes the original message will look something like this:

K2(R2, K1(R1, Ka (R0, M), A))

The message will first go to the mix K₂, which will unlock the outer layer using its private key, re-encrypt it using the random bit string R₂ and pass it along to the mix K₁. K₁ will perform decryption on the next layer, unlocking the encrypted message and A, the final destination.

Notice how there isn't actually an address in that layer? That is the second technique to hide where the message is going. If someone was quick enough they could essentially follow the path of each mix or messenger. To circumvent this, mix 1 doesn't actually send a direct message to mix 2, or even know where it is sending the message. It simply broadcasts that message out to the network. The other mixes will be able to see this message, but not be able to do anything with it. Mix 2, however, will recognize the message as one it can decode and pull in. This way, anyone listening wouldn't know which mix to listen in on next.

Finally, to prevent anyone from knowing the size of traffic that we are sending we append a random number of blocks of junk to our messages. At the final destination, the recipient will be able to throw away the junk and just keep what is useful. We should prefer a random number of additional blocks with each message, rather than just the maximum amount so as to not strain the resources of the network.

Okay, we did it. we sent a message to someone without anyone tracing it and not even the recipient knows who you are. Now if that is all you wanted, great your job is finished. What if you wanted them to respond to you?

You would need to enclose two pieces of information, your return address and your public key so that they could encrypt the return message for you. Obviously, you don't want them to know your address, so you give them an untraceable return address. As a result, the additional piece of information that you would have to add to your first message would look like this:

K1(R1, Ax), Kx

Where you provide your public key for the recipient to use, and a pre-encrypted return address, only able to be decoded by mix 1 on the return journey. Ideally, the return path would also be sent through a cascade so that the metadata is diffused.

So what?

If you are reading this you might have asked yourself this same question. You have been using the internet for as long as you can remember and have never had to worry about any of this. That is because protocols such as SSL, TLS, and HTTPS have utilized these concepts for you, to ensure that your business stays your business.

That said, it is ultimately your responsibility to understand these protocols and the protections that you are and are not afforded by them. For example, the lock at the front of your URL indicates to you that you are using HTTPS. If you do not have a lock you should be aware that none of your traffic is being encrypted.

Further, what was discussed in Chaum's paper is known today as end-to-end encryption. You are not guaranteed to have end-to-end encryption, even when you are using HTTPS. Many servers support just transport layer encryption. These servers intercept your traffic as an intermediary before they send your information onward. They are able to unlock your message because you are actually encrypting your information against their public key and not the final destination's key. These servers can read your message, store the information, and might not even re-encrypt the message before they send it onward! You should ensure that you are on a site that maintains end-to-end encryption, or you could encrypt the underlying data first before it is sent out on the web.

Another reality is RSA encryption (the most common key-pair encryption algorithm) is quite resource-intensive. It is much more common for this to be used only to create a secure session, called a TLS handshake. This essentially uses public-key encryption to pass a symmetrical key to the party you are interacting with. This key is known as a session key and will be used to encrypt and decrypt messages on both sides for the duration of the session.

Elliptical Curve Cryptography (ECC) is quickly overtaking RSA as the future of public-key encryption. It avoids some of the vulnerabilities of RSA such as poorly chosen primes, padded oracle attacks, and computational strain. Further, ECC offers similar levels of protection with much shorter keys.

We have never been more at risk than today as malicious users seek to take advantage of the inexperienced. We must learn how to use the tools available to us to protect our information. These protocols will all keep you safe so long as you are actually using them correctly.