Encryption Made Simple

If you're like me, you've probably heard someone or some webpage mention "public key encryption" or maybe something about "public/private key pairs" and stuff like that. And if you're still like me, your eyes just sort of glazed over and you stored it away in the "things to learn later" part of your brain. Fear not, this stuff is WAY easier than most people make it sound, and you can learn the basics right here, right now.

You don't have to be a programmer, either - this article is meant to be an easy-to-read, conceptual guide for everyone, so let's get started!


Symmetry
I am not a fan of using big words when smaller ones will do. However, you should probably be familiar with the term "symmetry." If you've never taken a geometry class or have never heard of symmetry before, symmetry basically just means "the same thing on either side." So if you split a perfectly-shaped apple exactly in half, the two sides would be considered "symmetrical."

Asymmetry is just the opposite. So if you were to cut the same apple into two pieces and one piece was larger than the other, then those pieces would be "asymmetrical." Technically, they still fit together to make an apple, but one piece is different than the other.


Encryption, Decryption, and Ciphers
Encryption (in computer land) is simply the process of trying to turn something readable into something that isn't readable, usually for the sake of keeping it private. If I were to write you a letter and wanted to keep it secret, then I could come up with some special code where I replace all the E's with 1, and all the C's with 2 and all the T's with 3, and so on.  Let's assume I used the below translation:

  E = 1
  C = 2
  T = 3
  O = 4
  A = 5
  I = 6
  H = 7
  (space) = 8

So my original letter:

  I hope you can read this!

turns into:

  6874p18y4u825n8r15d8376s!

Turning the original into the scrambled version is called encryption.

If you happened to have a copy of that table above, you could turn the numbers BACK into the original letters/spaces and you would be able to read the original letter.  Turning the scrambled version back into the original is called decryption.

Of course, if you don't have my special translation table above, then you would be hopelessly lost, and you could NEVER figure out my super-secret code, so you'd NEVER be able to read the original. ;) Okay, so maybe not NEVER, but it would at least take you a minute or two to figure it out.

And of course, that is simply MY translation table. Someone else could use a similar table but use different numbers or maybe replace different letters. Or maybe something even WAY more complex. Whatever the case may be, that special, secret METHOD for encrypting and decrypting is called a "cipher."

This whole process is very similar to keys and locks in real life. If I had a house with a lock on the front door, I could lock my house with my key to make it safe from robbers while I'm away. When I get back home, I use the same key to unlock the house. I could also make duplicate copies of my little key and give them to family and friends (that I trust), and then THEY could also unlock my front door and get in, too. And hopefully they wouldn't rob me.


Symmetrical Cryptography
So just in case you haven't guessed yet, "cryptography" is just the whole concept of encryption, and decryption, and ciphers and all that. A lot of people use "encryption" and "cryptography" the same way (although they shouldn't).

Symmetrical cryptography sounds a lot more complex than it is. The example I gave above with the same physical key unlocking my house's front door? Yeah, that's an example of symmetrical cryptography. All "symmetrical cryptography" means is that the same key that locks the door can ALSO unlock the door. It means there is one key that does both jobs - encrypting AND decrypting.

Symmetrical cryptography has been around for ages. It's also the easiest type to hack, because it usually involves multiple people having copies of the same key. As a result, it's easier for one of those people to make a mistake and leave a password or a key lying around for someone else to steal.


Making Things Harder / Seeding
Most symmetrical cryptography does not rely on turning certain letters into numbers or the other way around. There are far more complex ciphers out there that will turn a simple letter "A" into "15aZXP{].r" if it is the first letter of a sentence, or "9176dmeqp" if the "A" comes after a vowel, or some nonsense like that. The ciphers can get really complicated really quickly, especially since most are based off a password.

Let's say that you had a cipher that simply went through the original message and shifted every letter "up" by 2 letters. So every "A" became "C", "B" became "D", "C" became "E", etc etc etc... "S" because "U" and so on. In table format, it would look like this:

   A = C
   B = D
   C = E
   D = F
   E = G
   F = H
   ...etc...

A cipher like this would encrypt "APPLE" into "CRRNG", right?

Now let's say that right before you told the system to encrypt "APPLE", it asked you for a number between 1 and 5. If you told it "1", then it shifted all the letters by 1 character. "A" = "B" and "B" = "C" and so on.

If you told it "2", then you would get the original cipher that you see in the table above. If you said "3", then everything would be shifted by 3 characters, and so on.

By having this extra piece of information, it instantly becomes harder for a hacker to break the code. Now they don't just need the cipher - they need to know the number that you put in. If you encrypted APPLE with 2 and it became CRRNG, then trying to decrypt using any number except for 2 will result in gibberish.

In the real world, ciphers are a bit more complex than that. You usually give it a full password instead of a number, and it uses each part of that password in a different way to encrypt things.

Whenever you give an extra piece of information to a cipher in order to change how it encrypts and decrypts something, you are "seeding" it.

While it does make things even harder to crack, symmetrical cryptography has one big problem. If a hacker gets a hold of the password, then it doesn't matter how complex the cipher is - the password is the golden key that unlocks the door without any guessing or hacking involved.

With the internet comes a need for secure communications. Two people need to be able to send data back and forth securely, which means that they both need that password to encrypt and decrypt their ultra-secret messages, right? However, often times person A is in the United States and person B is in Japan, and it makes it difficult for person A to call person B to let them know what the password is.

If only there could be a way that person A and B could securely send their messages without needing to give each other a secret password first...

(I am a terrible, terrible writer when it comes to not giving things away, so you can probably guess what topic is coming next.)


Asymmetrical Cryptography
Just like symmetrical cryptography, ASYMMETRICAL cryptography is a lot simpler than it sounds. Everyone uses the same example because it makes the most sense, so here it goes....

You know those mailboxes on the street where you just dump your letters? They have those tiny slots so you can put your letters in, but YOU can't get them back out. The post office does this so YOU (yes, untrustworthy little you) cannot just start grabbing other peoples' letters, too. (Don't pretend like you've never wanted to open up the mailbox and grab a bunch of letters and run off with them!)

HOWEVER, a postal worker has a special key that he/she uses to open up that mailbox, so he/she can gather up ALL the letters inside and take them home to read them (and occasionally deliver them, too).

Getting back to the analogy, you have a system where a lot of people can "safely" give their letters, but they can't get them back. Only the postal worker person has the means to open up the mailbox.

This is a good analogy for asymmetric cryptography. It simply means that instead of one key being able to encrypt AND decrypt things, you have one key that encrypts/locks and another, DIFFERENT key that decrypts/unlocks.

In my previous house analogy, I could give my friends and family a set of keys that only locked my house. That way, if they were staying with me and needed to go somewhere, they could lock the house as they left, but only I could unlock the house again. This would relieve my paranoia about my friends and family robbing me.


Asymmetrical Cryptography = Public/Private Keys
So to tie this all together now, let's talk about the house example again. There are two types of keys - the "public" key and the "private" key. The "public" key is the one that locks/encrypts. I can give this key out to anyone (the public). In fact, I'd probably make a bunch of copies of this public key to give out because it doesn't let anyone rob me, even if one of the keys were lost or accidentally given to a professional thief. The thief couldn't unlock my door with the public key - he could only lock it, so it would be useless to him.

Of course, MY key can unlock my front door. This is my "private" key because I don't share it or make copies for anyone (unless I REALLY REALLY trust those people). Without the private key, I can't unlock/decrypt anything.

And obviously, MY private key doesn't unlock anyone else's door. It only works on that one door lock. Similarly, the public key that I give to someone only locks that same door.


How Is This Even Remotely Helpful To Anyone?
This was the biggest stumbling block to me. If I want to send someone an encrypted message, this whole private/public thing doesn't make any sense. They would need my private key to decrypt the message, and I'm not supposed to share it, right?

The biggest concept here is that public/private key cryptography (or asymmetrical cryptography or whatever you want to call it) is not about YOU SENDING things securely. It's about you RECEIVING things securely from other people.

By giving other people a public key, you're giving THEM the ABILITY to safely and securely send YOU some data... all without ever needing to share any super-secret password with them.


A Real-Life Example
Anytime you've ever gone to a secure web page where the URL started with https://, you are using public key cryptography, but you probably didn't know that.

Your browser (Internet Explorer, Firefox, Safari, or whatever) begins by talking to the web server and sending it a request for a secure connection. The web server already has private/public keys set up, so it responds and provides your browser automatically with the public key. Your browser then says, "I'm going to encrypt this credit card number with this public key that I just got." and it does that, turning the credit card information (and everything else it is going to send) into some awful mess of weird characters and gibberish.

Then your browser sends the whole mess back to the server. The server takes the mess and unlocks it with its private key. Just like that, there's been some data exchanged securely!


Common Questions
Usually people now ask, "So can't a hacker keep generating lots of private keys and keep trying different ones until one unlocks the data?" The answer is yes, a hacker could theoretically generate a valid private key and decrypt ANY data that had been encrypted with the public key. However, each key is pretty complicated and lengthy. Even with powerful supercomputers at your disposal, it would still take a LONG time to correctly guess the key. Generally speaking, the average hacker simply doesn't have access to the resources needed to randomly generate the correct private key. It would take current computers YEARS and YEARS of constantly trying new combinations. Even multiple computers working together to do it would still take a long time. For most hackers, it just isn't worth the time and effort to crack these keys.

"Computer processors keep growing more and more powerful every year, so won't that quickly cut down on the cracking time?" The answer is yes, but it's very easy to simply make a key longer. Each time the key gets a little bit longer, it gets exponentially harder to crack. Making keys longer is an easy answer to the increasing power of computers.

"How can a public key ONLY be able to encrypt?" This is understandably confusing. How do you encrypt something without knowing how you did it? It may be easier to think of your browser as having access to a tiny machine that does nothing but suck in data and a public key and spit out encrypted data. That factory contains a bunch of different ciphers (the formulas used to encode something) inside it. But remember how we talked about seeding and how adding a password made the whole thing even harder to crack? Imagine if your password/seed was hundreds of numbers long! The public key is sort of used as a really long password/seed for those ciphers. So your browser basically feeds that public key into its special factory, which spits out the encrypted data in a way that can't be reversed by just shoving the data back into the factory with your public key. Once the data leaves the factory, it locks the front door on the way out.

If you want to play around with these concepts, you should probably check out OpenSSL ( www.openssl.org), which is basically a free version of that tiny machine I just talked about. It's a wonderful little machine that can do just about anything (cryptography-related) you want.


Certificates
I don't think I've mentioned certificates yet. Just so you're familiar with the term, certificates are simply files that hold the public/private keys. They're pretty much just a digital version of a good ol' briefcase. Sometimes public/private keys can have a bunch of parts (e.g. a chain of different keys that make up a bigger one), so a certificate file makes a nice carrying case for holding them all in one file that is easy to transfer / maintain / etc.

Certificates come in different formats. Some certificates hold all the keys together, others just hold public OR private keys, and others might hold other information related to the keys. Ultimately, different formats sometimes have different purposes, and sometimes it's just a simple formatting difference, like saving a Word document versus a Wordpad document - they both can contain the same letter to your mother, with all the right words bolded, but when you save them, the binary guts inside the file look different.


Trust and Certificate Authorities - Would You Take Candy from a Stranger?
There's one last piece to this whole puzzle that you should know about: trust. Trust is a big thing... maybe the BIGGEST thing in the online world, because it's hard to know WHO you can trust. Let's say that you go to a store and at the checkout counter you see a sign saying, "The credit card swiping machine at this checkout counter has been thoroughly checked for safety and security problems by Jerry, our security guard who is really interested in hacking." - would you swipe your credit card at that machine? Probably not, unless you have trouble mentally inserting spaces into words.

However, if the sign said that it was checked by Bank of America or CitiBank or some other large financial institution, you MIGHT be more comfortable with swiping your card. At least you're dealing with someone you know instead of Jerry, right?

In the online world, every security certificate is created (also known as "issued") by some company or organization called a Certificate Authority, or CA for short. Technically speaking, ANYONE can become a CA. All it takes is for you to have your own special security certificate that says you are a CA, and you can easily use OpenSSL to create one of those certificates.

It's much like buying your own "Certificate of Excellence" award from your local office supply store and writing whatever you want on it. You CAN do it, but it's not going to impress anyone, because the award isn't coming from any sort of university or company that is well-known. If you put it on your resume, people probably aren't going to care, because again, it isn't from any place that is well-known - it's just from you.

Security certificates undergo the same kind of "respect" system. Every certificate is issued by a Certificate Authority. The "trustworthiness" of the certificate depends on how trustworthy the CA is.

If you used OpenSSL and created your own homegrown CA called "Myself, Inc.", and then used your CA to create a security certificate for yourself (this is referred to as a "self-signed certificate"), then anytime anyone saw your self-signed certificate, they could see that your certificate was issued by "Myself, Inc.". The person would then wonder, "Who in the world is Myself, Inc.?" Then they would say, "Well, if I've never heard of Myself, Inc., then I'm not sure I can trust anything that they give out."

Let's take the above example and put it into a real-world scenario. So let's say you've used your self-signed certificate to secure your web site. Then you send out an email to your friend Bob, saying, "Hi Bob, I figured out how to create self-signed certificate - come check out my secure web site at https://www.mysite.com!" Bob gets the email and clicks on the link, and his browser goes to https://www.mysite.com... and then sees a warning message pop up! The warning message basically says, "HEY! You're about to go to a secure web site, but the certificate didn't come from anyone I know!" At this point, Bob can tell his browser to go ahead anyway (if he trusts you), or if he doesn't completely trust you, he probably will just hit cancel and not go to your web site (which can be disastrous if you're trying to sell something and you've just lost Bob as a customer).

You might be wondering what would happen if Bob were to continue to the web site - would it be secure? The answer is yes, it would be. However, just because the encryption/decryption is secure doesn't mean that Bob should trust you with his credit card number.

There are some possible technical dangers with a self-signed certificate (if you were a genius-level hacker), but it also means that YOU didn't go through any sort of auditing process in the real world to verify that you are a trustworthy company (something that a well-known CA would do before giving you a security certificate).

Hopefully by now, you're asking, "How do you become a well-known CA? How does the browser know which CAs are well-known?"

There ARE some well-known Certificate Authorities out there. You've probably heard of Verisign or Thawte before. You've probably heard of them because they've been around so long. A CA becomes well-known when they have proven themselves secure and trustworthy, and as a result, they are put into a list that usually comes with your computer. That list is most commonly called the "Trusted Root Certification Authorities" list. Any CA that is named inside that list will be considered to be a "well-known" CA, and any certificates that are issued by those CAs will be considered trustworthy. In other words, if your browser goes to a web site that is secured by a certificate from Verisign or some other well-known/trusted CA, then it won't throw up any sort of warning message.

That list of trusted CAs -CAN- be updated. Operating system makers like Microsoft usually release updates to their lists every once in a while as new CAs become trustworthy enough to be added to the list. However, a LOT of people simply don't update their lists, so they pretty much only trust whatever CAs were trusted when they bought their computer. As a result, the longer the CA has been in business, the higher the chance that it will be in a trusted root CA list.

That's usually why certificates from older CAs are more expensive - they're usually trusted by more people than certificates from newer CAs. They're not necessarily BETTER or more secure - they're simply trusted by more computers. In some cases, the CA itself is well-known enough (like Verisign) that they charge a bit more for their certificates for the name recognition.

One other thing about well-known CAs that you should know - most well-known CAs will require their potential customers to prove themselves to be a valid business or organization before selling a certificate. Sometimes this is a multiple-day process where mailing addresses are verified and stuff like that, and other times it is just a matter of faxing over a valid driver's license. It depends on what kind of certificate you're trying to get, and what CA you're getting it from.


The Value of Self-Signed Certificates
If this hasn't sunk in yet, I should point out that self-signed certificates CAN be useful. They may not be good to use for ecommerce web sites - you don't want to scare away your visitors with a warning message (even if they would be safe), but they can be very useful for securing intranets or other small, private projects. Since you have the ability to tell your OWN computer that "Myself, Inc." is a trustworthy CA, you can set up your own computer to trust all of your self-signed certificates.

If you were working in a small team of 5 developers or something, you could easily update all 5 computers to also trust "Myself, Inc." and all of its certificates, and you could use them to set up a secure development environment, free of charge!

Bottom line: You don't need to pay big bucks to secure anything that is only accessed by a few people.


Wrapping Up / Revocation
Congratulations! You now have a pretty good working knowledge of certificates, public/private keys, and general-purpose cryptography. Like this article (hopefully), all good things must come to an end, which brings up the very last point: revocation.

Most certificates can be revoked (taken back or marked as "bad") by whatever CA issued them. When a CA creates a certificate, it puts a little URL inside that says, "Check the list at this URL to see if this certificate is still good and valid." When the browser is about to use the certificate, it should go out and check that URL. That URL should contain a list called a "Certificate Revocation List" or CRL for short.

If the browser looks at that list and sees that the certificate it is about to use is in that list, then it means that the certificate has been revoked and should not be trusted / used. Why would this happen?

There are a few reasons, but the biggest reason is that the private key (the key that can decrypt all the data) has been stolen. Somehow, a hacker got onto a server, found the private key, and copied it. Then the server administrator found out and yelled something that I can't repeat here, then contacted the CA and told them about the security breach. The CA tells the administrator to remain calm and simply adds the certificate onto that CRL list and gives out a new certificate.

Within 24 hours, nobody should be using that old certificate/public key to encrypt data, and the stolen private key has lost all of its value because it can't decrypt anything sent by the new certificate.

I'll end with a terminology cheat sheet:

    Symmetrical Cryptography = A system where the same key can encrypt AND decrypt data

    Asymmetrical Cryptography = A system where one key encrypts data, and another key decrypts it

    Public Key = Encrypts data but cannot decrypt data

    Private Key = Decrypts data that has been encrypted with the public key

    Cipher = A formula used to encrypt data

    Seed = Something that is "fed" to a cipher to make it more random and difficult to hack

    Certificate = A digital "briefcase" that can hold public and/or private keys

    CA = Certificate Authority (issues certificates)

    CRL = Certificate Revocation List (a list of certificates that should not be trusted / used)

    Self-Signed Certificate = A certificate created by a CA that you also created

    OpenSSL = An open-source toolkit that does all sorts of certificate-related things

Thanks for reading!

Copyright  ©  2010 - Jonathan Hilgeman. All Rights Reserved.