Three kinds of encryption dominate the scene. They are Symmetric, Asymmetric and Hashing. Each has its own application. The ConsenCIS framework makes good use of all three.

Hash functions convert plain text into a cipher (or hash) that cannot be decrypted. You might wonder why this would be useful. It is great for storing passwords. You don't need to store the password, just its hash. When a user wants to login using the password you just hash what he provides as a password and compare it to the stored hash. If they match, he has provided the correct password. Hash functions are cool because no matter what input you provide they generate a unique hash (no conflicts). Good ones like the popular SHA-1 algorithm are blazingly fast.

Symmetric encryption allows both encryption and decryption of a message. It requires that both the sender and the receiver have a copy of the key. The key is used to code (encrypt) and decode (decrypt) the message. The message start life as "clear text" (i.e. a readable message). It is encrypted using the key into "cipher text". The cipher text can be transmitted across a public network because it is unreadable without the key. The receiver uses the same key to decrypt it back into clear text. Symmetric encryption is fast and efficient but if someone gets hold of a copy of the key he can read everything, write bogus messages, and generally make a mess of things.

Asymmetric encryption is much cooler but a bit more computationally intensive. It relies on a math concept called a one-way function. You use the one way function to generate two keys. A message encrypted with one member of the key pair can be decrypted with the other and vice versa.

One key of a pair is for the sender and the other for the receiver. The sender uses his key, we'll call this one the public key to encrypt a message. The cipher text can not be decrypted with the sender's key. It can only be decrypted using the other key. We call the second key, the one held only by the receiver, the private key.

---

Using asymmetric encryption can use a little further explanation to understand how it is useful.

Lets say you want to send a message to someone. If that person can generated a key pair, you can ask for his public key. He sends you a copy, you use it to encrypt the message. You then send him the cypher text. He uses his private key to decrypt the message. There is no way for anyone else to read the cipher text or guess the contents of the private key.

Lets say you receive instructions from some one to perform a transaction. Maybe they want to buy 100 shares of IBM stock. You want to be sure the sender is who he claims to be. If he has a key pair and you have a copy of his public key, he can use his private key to encrypt his name and send it to you. Anyone with the public key can decrypt it, but only the private key holder can encrypt a message to be decrypted by that public key. There are problems with this method, not the least of which is that once he sends his encrypted signature the cipher text could be intercepted. An attacker could later use the intercepted cipher text to fool you into believing he is the authorized sender. So we need to further protect signatures in transit.

There is an even better way to authenticate someone's identity. He has to initially register his identity when he sets up an account. At this step he requests a public key which you generate and send. He  uses the public key to send you an id and a password which you decrypt, hash and store. When he wants to authenticate his identity in the future he asks you to generate another key pair and send him the public key. He uses it to encrypt his id and hashed password which he sends back to you. You decrypt with the private key and compare the id and password hash to your records on file. If they match, he is the person who originally registered that id. The key pairs are used once and then discarded.

This second method is invulnerable to most forms of attack. One way to attack it requires the user be inattentive. The attacker must create a login screen that looks just like the one used by the system he is trying to invade. Then he fools an authorized user into connecting to the look alike screen, perhaps using an email message containing a direct link to the look alike. Then when the user sends his password, the attacker decodes it and uses it to gain entry to the target system. The user must be inattentive because the look alike screen may look just like yours but it will not have the same URI in the address line. It would probably be easier to use weak password guessing or social engineering ("dumpster diving," etc.) to steal your password.

One more attack has to do with the registration step. An attacker might try to register under an assumed identity from the very start. He might claim to the Pope.  To get around this possibility some systems require users to register with an authentication authority. The authority is a company setup to investigate claimed identities and then when they are satisfied the user is who he claims to be they generate a key pair for his use. He takes the private key stores it on his system securely and uses it to decrypt messages and encrypt his digital signature. The Authority posts his public key on their site for use by the people who want to send him a secure message or verify that a message is actually coming from him.

One more step has to do with the relative speed of symmetric and asymmetric encryption. Symmetric encryption is almost 100 times faster. But getting each user to have the same key can be a problem. So we send the message in steps. First we send the symmetric key as a message using an asymmetric key to protect it. Then we use the symmetric key to send the actual  message.

The sender generates a key pair and sends the public key to the receiver with his request to exchange a secure message. The receiver generates a symmetric key encrypts it with the senders public key and sends it back. The sender uses the symmetric key to encrypt the lengthy message and sends it to the receiver who uses his copy of the symmetric key to decrypt the message.

The only way to attack this system is to spoof the receiver's first reply. So an attacker must listen to the receiver's incoming messages and when he sees a request for a secure message he needs to reply with a bogus symmetric key before the legitimate receiver replies. His message will have to appear to come from the legitimate receiver in all regards so it needs to contain the receiver's IP address. The sender could then be fooled into encrypting his message with the attacker provided symmetric key.

To prevent this attack the receiver must include his digital signature with the message he sends back to the sender. If the sender can authenticate the signature, he can trust the symmetric key.

Now if this is beginning to sound complicated, you are understanding the initial dimensions of the problem. Security is complex. It revolves around how dedicated attackers can be to exploiting a weakness. When money is involved you can understand why attackers would be wiling to spend the time and effort. ConsenCIS makes it easier, but security is definitely a committment and requires a frame of mind.