Digital Signatures & Encryption

Thanks for visiting. Please consider joining over 15,000 other readers in subscribing to our RSS feed or following us on Twitter.

In this post, we are going to look at the fundamentals behind sending encrypted emails and documents.  The idea is to show you the concepts so you understand what is going on behind the scenes to make a secure communication channel over email.

So why spend the time on this?  As we switch to doing more business over the internet, secure communications are going to become much more important.  Even if you don’t have a use for encryption right now, you probably will over the next 3 to 5 years (if not before).  There is a lot of value in understanding why encrypted emails are secure–even if you don’t understand all the complicated math behind it.

I find it frustrating that so few people and businesses use encryption on their emails.  If businesses would use encrypted emails, they could just send me a PDF of my bill instead of requiring me to login and download my bill from their website. Many of the processes that currently require printing on dead trees and then using dead dinosaurs to transport sheets of paper through the mail could be done electronically if more people would use encryption.  This article is me doing my little part to help raise awareness of how encryption works. If you want to help save paper and think this article is useful, please pass it on to someone else.

Encrypting a Document

Digital signatures are used to do two things.  First, they are used to encrypt files and emails so that they can only be read by the person they are intended for.  Second, they can be used to “sign” a document to guarantee that it arrives in the same state it was originally sent and no one has added or changed things.

A digital signature consists of a public and private key.  Your public key is shared with everyone.  Your private key is kept private.  These keys are text documents full of what appears to be random numbers and letters, but with the proper algorithm, these numbers and letters have a very unique property.

If you take a document and run it through an algorithm with your public key, you get back an encrypted document.

Once it is encrypted, the public key can’t be used to decrypt the document. The process is one way so it doesn’t matter if other people have the public key, they can’t read the document.

To decrypt the document you must have the private key.  If you give the encrypted document to an algorithm with the private key, you will get back the original document.

An Example

Lets start with Tom and Suzie.  They want to communicate securely to keep Hitler from reading their messages.

First Tom, sends Suzie his public key.  This usually happens automatically when Tom sends Suzie a normal email message.  Their email programs handle sending Tom’s key and recording it on Suzie’s side of things. When Suzie sends Tom a regular message, Tom gets her key as well.

Suzie takes Tom’s public key and uses it to encrypt an important message.  Then she emails the encrypted message to Tom.

But wait! Hitler intercepts the message by infiltrating Suzie’s ISP and breaking into her email.  He now has the encrypted message that Suzie sent to Tom.  Hitler also has Tom’s public key that Tom sent to Suzie.  However, no matter what Hitler does with the public key, he can’t decrypt the message.  The only thing that can decrypt the message is the private key that Tom keeps safe.

When Tom gets the message from Suzy, he takes his private key and uses that to decrypt the message.  He can now read Suzie’s email.  It doesn’t matter who else gets a copy of the email that Suzie sent. Tom is the only one who can unlock it as long has he doesn’t share his private key.  If he wants to reply to Suzie, he simply uses her public key to encrypt his reply and sends it back to her.

Signing a Document

With an understanding of how documents can be encrypted, we can look at how to “sign” a document.  An encrypted document does three things.

1. It guarantees that the document was actually sent by the sender.
2. It guarantees that the document wasn’t modified in route.
3. It guarantees that no one else can read the document.

For a lot of communication, item three isn’t necessary or even desired.  For example, if I want to send a message out to 25 people, chances are pretty high that it isn’t extremely confidential.  In fact, sending a separate message to each person encrypted with their public key might be quite a burden for me.  However, I still may want each recipient to be guaranteed that the document came from me and that it wasn’t modified in transit.

Outside of email, I may want to post a message on a website that can be read by the world where anyone can check to make sure that the message hasn’t been changed from when I wrote it and confirm that it was truly written by me.  A slightly different example of this is when a company posts a piece of software or a patch for existing software.  The people who will download it  want some way to know that they are getting a legitimate file and not a virus that was posted by hackers to trick people.

This is where signing a document (or file) comes into play. Signing a document guarantees the first two items on the list, but does it in a way that allows anyone to read it.

This can be difficult to explain, so I am going to simplify the math a bit.  My version won’t be quite as secure as what is actually used, but it will give you a good general idea of how it operates.

Checksums

First, let’s talk about checksums.  A checksum is a simple way to send an extra piece of information along with some data that can be used to make sure that the data is the same on both sides.  In human terms, this is kind of like asking someone to repeat a number back to you over the phone.  While repeating information back works fine for short numbers, it could be a bit troubling if you have large amounts of data.  So we create a short cut.  Let’s say that, for some reason, I’m trying to give you the values of 100 checks over the phone.  I’m reading them from Excel and you are typing them into Excel.  In the end, we want to make sure that we didn’t miss anything.  I could have you repeat all the numbers back to me, but that would take a long time.  Instead, I might ask you to give me the total.  If your total matches my total, then one of two things happened:

1. We successfully transferred the numbers verbally.
2. We made some mistakes that perfectly canceled each other out.

Since option two is pretty unlikely when dealing with a large list of numbers, we can assume (with a reasonable degree of certainty) that we didn’t make a mistake.

Computers use checksums in a similar way.  Back in the days of modems, computers would send an 8 bit byte where the last bit was a checksum.  So, the computer might send a binary message that looked like this:

01101010

The first 7 bits contained the data: 0110101.  The last bit is the checksum was used to tell if there were an even or odd numbers of ones present in the data.  In this case we are using a 0 to say that there are an even number of ones.  If the receiving computer got a byte where the number of even bits and the checksum bit disagreed, it would ask for that data to be sent again.

This type of approach reduces accidental errors.  However, it does nothing toward preventing someone from intentionally changing the data.  If you wanted to change the data en route, it would be simple to flip the checksum bits to match whatever you wanted to send in the data.  We need a way of generating a checksum type value that is hard to fake.

Hashes

In simple form, a hash is an algorithm (or set of steps) that you can run a piece of data through (text, a file, etc.) and get out a number that represents the original. You can’t recreate the original from the number, but for most practical purposes you can use that number to represent the input.  In other words, it will be very difficult to find another input file (or text) that will produce the same output.

Let’s construct a simple hash of the following text:

The quick brown fox jumped over the lazy hound.

Our hash is going to be created by multiplying the number of letters by the number of words.

38 letters
9 words
38 x 9 = 342

So now if I send you this message, I can include the number 342.  You can do the math on the message you receive and it will give you a pretty good idea if the message is the same as what was sent.

Obviously, this type of solution will only protect against unintentional changes in the data.  If someone  changes the email in route, they could just as easily change the number “342″ to match whatever the hash is for their modified message.

If we want to protect against this, I can send the hash value through a different channel.  For example, I could send you the message via email and then call you on a secure phone line and say, “the hash value is 342″.  That way if someone wanted to modify the message, they could only change it to something that produced a hash value of 342.  (In our very simple hash algorithm, this would be hard, but doable. With the complex hash algorithms that are actually used, it would be impossible, for all practical purposes.)

Obviously, it is inefficient if I have to call you up on the phone. We need some way to put a secure channel in the email.  If I try to encrypt the hash number with your public key, the message is only readable by you–I might as well just encrypt the whole message.  If I encrypt it with my public key, then I’m the only one who can read it–not particularly useful either.

But look what happens when I encrypt it with my private key.

We now have the value 342 encrypted in a way that can be opened by anyone with my public key. Since my public key is the only thing that can decrypt that value, it guarantees them that I was the one who originally encrypted the number 342.

If someone wants to change the message and change the hash value, they would have to be able to encrypt it with my private key.

So, when you send a signed message, the hash value guarantees that the message hasn’t been changed.  Encrypting the hash value with your public key guarantees that the hash value, itself, hasn’t been changed.  This is normally handled automatically by your software, and it will give you a warning if you get a message where decrypting the hash value produces a different number.  The encrypted hash value is added as a small attachment or added to the bottom of the email.

Conclusion

And there you have it.  You now understand encryption better than 99% of the population.  If you are interested in starting to use encryption for email, I recommend getting  a free set of certificates from Thawte or Comodo. (Thawte may be canceling their free program, so Comodo may be the better choice.) The setup process is fairly simple and they have instructions on how to get various email clients configured.

As I said before, this article is me trying to do my part to help society move from paper to digital.  If you want to help, please take a few minutes to share this with someone else.