Adapted from `Tom Swift® and His Encryption Machine' at http://www.rnbo.com - altered to contain a somewhat less patronising explanation of encryption. All content is copyright© to Rainbow Technologies. We make no claim to have contributed in any way to the authorship of this document, but have found it to contain an excellent, not-too-technical description.

Below is a description of how encryption functions. Most of this is what goes on `behind the scenes' - it describes the steps your computer takes and explains why encryption works so well. From the user's point of view, all that must be done is to ensure that documents are actually passing through the encryption process, and this is always reported by mailing or browsing software.

Encryption

Encrypting a documents or other pieces of information involves translating them in a way that makes them unintelligible to anyone trying to read it. Of course, you have to know how to undo the translation (decryption) so the document can be read by the recipent.

It's called cryptography, and it's really been around for a long time. Early encryption used very simple substitution methods, or algorithms. For instance A is replaced by D, B replaced by E, etc. so that "dog" would become "fqi." Not very sophisticated, and pretty easy to "break." Julius Caesar even used this technique to communicate with his generals. The list of substitutions was the "key" necessary to decode the message.

Another type of encryption, called a transposition cipher, is where the order of the characters in a message is rearranged according to some predetermined method, rendering the message unintelligible. In the 5th century BC the rulers of Sparta used a mechanical device called a scytale do this kind of transposition. The scytale was the `key' to both encrypt and decrypt the message.

But with the power of today's calculating machines, algorithms like those are not strong enough. The processes used today are similar, but the algorithms are much more sophisticated. The ones used today mostly fall into two main categories - the first, symmetric or secret key, and the other, public/private key pairs. Both these technologies use a key in both the encryption and decryption processes.

Symmetric Encryption

The first process is called symmetric because the same key is used to both encrypt the data and then to decrypt it. Symmetric encryption algorithms (also called block encryption algorithms), like the Data Encryption Standard (DES) designed in the early `70s by IBM and certified by the U.S. government, are designed to be fast. The problem with them is that everyone who has to have access to the data, either the originator or any receiver must have the same key. This means that you also have to have a way to distribute the keys, and a way to protect the key at each location.

Since several people may have the key, if you receive a message encrypted by the common key, you have no way of knowing that the message was not intercepted and changed by one of the others with the key. This problem can be minimized by having a separate secret key for each pair of individuals. But this in turn raises a different problem - managing the keys for a large number of people requires a complex and highly secure key management system and the number of keys skyrockets as the number of people increases.

While symmetric encryption is very fast, it has significant problems managing and protecting the keys used.

Public Key Systems

An encryption system was developed in which each individual is given a pair of keys - a Private Key and a Public Key. In fact, you could have multiple key pairs for different aspects of your environment. For instance you might have a key pair for your bank, one for your work and one for personal communications with your patent lawyers. Each pair of keys have the unique characteristic that each key can unlock only what the other one of the pair has locked, or in cryptographic terms decrypt only what the other key has encrypted. The Private Keys are kept safe so only you have access to it. Public Keys are published in a directory much like a telephone directory so anyone can get it.

If you would want to send something to your lawyers and keep it secret from everyone else, you would encrypt it using their company Public Key and know that only they could decrypt it. Since no one else has their Private Key, the document would remain safe from anyone else's prying eyes. Even you couldn't decrypt the message you sent since you do not have their Private Key (of course you would still have the original text).

Similarly, if you encrypt something with your Private Key, then someone who has your Public Key can decrypt it, and because they can decrypt it, they know that only your Private Key could have encrypted it. This characteristic provides a very valuable attribute. If you keep your Private Key safe so that no one else ever has access to it, and if someone else receives a document that is successfully decrypted by your Public Key then they know that only you as the owner of the corresponding Private Key could have encrypted the document and that you as the owner of the private key cannot deny having encrypting it. This process provides the basis for an electronic signature.

The drawback to this process is that encryption using a Public or Private Key is very slow even on today's fast calculating machines. This type of encryption uses multiplication and exponentiation of very large numbers, something that most calculating machines are not designed specifically to do. Consequently, public key encryption is not very useful for encrypting long documents and files.

One of the application of public key systems is to solve the problem of the distribution of secret keys. Instead of assigning secret keys to pairs of people, temporary secret keys are assigned to a document. The secret key process with its speed is used to encrypt the document. The secret key is then sent with the document but protected by the Public/Private Key process. Once used to decrypt the message, the secret key is discarded, eliminating the need for a bulky, difficult, secret key management system.

Document Encoding

In addition to secret key encryption and Public/Private key pairs, there is another mathematical process, called a `hash', that is used to complete the protocol. To `hash' a document means to use a mathematical formula to create a number that is unique to the document, not unlike the remainder from a long division problem. The number from a hash is referred to as a `message digest,'

Typically a message digest is 160 bits long. This process has several characteristics that are very important and very useful. The first is, that is not reversible, meaning that there is no way to recreate the document from the hash. It is a one way process. Once again, much like the remainder in a long division program. You can't figure out what the dividend was if all you have is the remainder. Likewise, you can't figure out the message from the message digest. This means that you can show the message digest to anybody, and not put your message at risk of being recreated and read by the wrong person.

The second very important characteristic is that if you change one character in the message or even one bit, the message digest will change dramatically. In fact over half the 160 bits will more likely than not change. Another advantage is that hash functions are reasonably fast to perform on today's calculating machines, depending of course on the length of the item being hashed.

The originator of a message sends both the message and the message digest to the intended receiver. Once the receiver has the message, they recalculate the message digest on their system using the same formula and compare the resulting value to the one that the sender included with the message. If the digest values are the same, then the receiver knows that the message has not changed.

However, this method is not really secure, since some attacker can just intercept the message, change it, calculate a new hash, and send both phony replacements along in place of the originals. So to provide security, the process has to get a little more sophisticated.

Secure Messaging

The way to provide safe, fast information transfer in secure messaging is to use all of the processes described above, taking advantage of the benefits of all, and minimizing the drawbacks.

Encrypting the message

Let's say that you want to send a confidential message. The first step is to make sure the information itself is safe, so the message is encrypted using a randomly generated secret key and a symmetric encryption algorithm. This is fast and easy to do on today's calculating machines. Then you take the secret key and encrypt it with the recipient's Public Key. Even though this is a complex mathematical process it doesn't take long because the key is very short.

Now you could send the encrypted message and the encrypted key to the recipient, knowing that only they can decrypt the secret key with their own Private Key and then decrypt the message. However, at this point the recipient knows nothing about the person sending the message. It could be somebody impersonating the real sender.

Signing the message

In the next step, you would create a digital `Signature' by hashing the message and then encrypting the resulting message digest with your private key. This signature is then sent with the encrypted message and the encrypted secret key to the recipient.

Decrypting the message at the destination

When the recipient receives the encrypted message, the encrypted secret key, and the signature, they first decrypt the Secret Key using their own Private Key. Next they use the secret key to decrypt the message.

Verifying the message

The recipient still needs to know that the message wasn't tampered with, so they hash the message they just decrypted, using the same formula as before, to get their own message digest. Then the recipient decrypts your signature using the your Public Key to obtain the message digest created by you. Since it decrypts with your Public Key they know only you could have sent it. Then they compare their message digest with the one sent with the message by you.

If message digests are the same, the recipient knows:

  1. only the owner of the public key could have sent the message
  2. that no one altered the message en route
  3. no one else could have read the message
  4. that the sender cannot deny signing the message