Symmetric Keys Are All the Same

Symmetric Keys Are All the Same

That’s a bad joke, of course. What I really mean is that symmetric algorithms all use one key to encrypt data and the same key to decrypt it. That’s why they are called symmetric. Your front door key is also symmetric — you use the same key to lock your door as you do to unlock it. The secret to the security of your front door is that you (hopefully) have the key with you at all times and you don’t give a copy to anyone else. If you do trust someone else with the key, it will always be an exact copy of the one you have.

The success of the key is how random the number is that starts the process of generating a key. There’s more on the randomness of numbers in a bit, but it’s important for you to know that the success — and failure — of some algorithms is directly related to the randomness of the number in the key.

The key table

When the user of a symmetric algorithm creates a key, most symmetric algorithms create a key table from the original key. This is also known as the key setup or initialization. Not to make things more confusing than they need to be, but it’s actually the key table that is used to encrypt the data. The trick is that the original key is mathematically tied to the key table so, as long as you have the original key, the key table can be created.

Think of the original key as a model or mold for all the other keys in the key table. It’s kind of like making a batch of muffins — they are all made from the same recipe (the original key), but none of them are exactly the same. I’m oversimplifying, of course, and I don’t want you to get too hung up on the key table concept. You’re bound to hear about it when discussing crypto products with vendors, though, so I want you to at least have a basic idea of what they are talking about. By the way, if a vendor tells you that their product reuses the key table, that’s a bad thing!

To better give you an example of how a key table works, I’ve created the following pretend key table. I’m using a portion of the alphabet as the key and then using the letters in that key to create alternate keys. Here’s a short example:









You’ll note that the keys in the key table are longer than the original key. That’s because the keys in the table are supposed to be longer than the original key. It’s just the way the algorithm was written. It’s not really important that you understand how a key table works.

Key generation and random numbers

The key in a symmetric algorithm starts with a number. Of course, the longer the number the better. When you create one key for one message and then another key for another message, you want to make sure that the numbers are not in sequence. If the key for your first message was 109374629, the key for your second message was 109374630, and the key for your third message was 109374631, an attack on the keys would be very easy because you could figure out the sequence of the starting numbers. But how do you make sure that the numbers are not in sequence or otherwise related to one another? You make them random.

It’s extremely difficult for the human mind to create truly random numbers because our minds are always trying to establish patterns from chaos. That’s why we see clouds that look like rabbits or horses or old ladies. Our minds won’t allow us to just accept the randomness of a cloud’s shape; it has to match the shape to something we are familiar with. It’s the same with numbers. We may start out with a random number or two, but eventually, we unconsciously start connecting numbers. For that reason, we give the task of creating random numbers to our computers.

A truly random number is based on an unknown quantity like the rate of radioactive decay, or the number of leaves that will fall off a tree today, or how many rust spots will appear on the hood of a car in a given month. These types of unknowns are referred to as entropy (EN-tro-pee). True entropy can produce random numbers that never return the same result twice in a row. In a computer, something that takes input from an entropic event and converts it to a number is called a random number generator (RNG). Intel makes a computer chip that reads the amount of thermal noise in your system to create a random number and other companies that manufacture cryptographic accelerators also use special chips as an RNG.

But, and here’s the big but, true RNGs are expensive, and it’s not economically feasible to include them in every computer. So, you do the next best thing; you devise a recipe — or algorithm — to create a pseudo-random number generator (PRNG). A PRNG generates random numbers, but it generates the same random numbers every time you run it. That’s a contradiction, isn’t it? Yet, it’s true. If you install a PRNG on one computer and generate a number, and then install it on another computer and generate a number, the numbers will be the same. The trick to using a PRNG is to grab another random number from some other source and mix that with the number from the PRNG.

 Tip  There is no fancy way to pronounce RNG or PRNG — you just say the individual letters.

To make the PRNG better, the PRNG takes some sort of other random input from your computer and mixes that up with the pseudo-random number from the PRNG to create another number. For example, the PRNG might use its number and then grab the time in milliseconds from your computer’s clock and add the two together. Or it might look at the last 1,000 keystrokes, mouse movements, and cursor locations that are stored in RAM, turn that data into a number, and add it to the PRNG. Whatever the case, the PRNG takes data from your computer, throws away the non-random stuff (like the month and year from the date), and mixes it with the number that it created on its own. This other random number is also known as a seed. This seed is “planted” with the PRNG and used to “grow” a number that eventually becomes the key.

If (and this is the big IF) the PRNG algorithm is good, it produces a good number that, in the end, generates a nice strong key. The failure to do this properly has been the downfall of many vendors’ attempts at creating strong encryption. Not to throw stones, but let’s take a look at Netscape. In its first version of SSL (Secure Sockets Layer, used to make secure Web connections), Netscape gathered data from the computer as the seed. The trouble is that the data they took could be easily figured out. Part of the seed was the year, month, day, hour, minute, and second of the transaction. It was a no-brainer to figure out the year, month, day, hour, and minute because all you had to do was look at the time the data was gathered. Figuring out which second the transaction took place took a maximum of 60 tries to get it right (because there are only 60 seconds in a minute). In practically no time, this weakness was made public — Netscape didn’t waste much time in getting version 2 out to market.

Protecting the Key

Now that you’ve created a long, strong key with which to encrypt your data, how the heck do you protect it? You can’t send it to your recipient in the clear because someone could intercept it and steal it. If someone can steal your key, they can decrypt your secret messages. What about hiding it? Well, hide it where? If the key is hidden, you still have to tell your recipient where it is hidden, and how do you do that without other people finding out? Everyone hides door keys beneath the doormat or under the flower pot, so you can’t do that. Even if it’s hidden in a good spot, you still have to tell your recipient how to find it. Are you going to send that person on an elaborate scavenger hunt just to find the key? That doesn’t make things very easy,  does it?

The answer is to encrypt the key. Pretty simple when you think about it, but pretty difficult to crack. Even if you find the key, you still have to decrypt it to be able to use it. An encrypted key no longer looks like a number — it looks like a series of random characters from your keyboard, almost as if your cat had walked on your keyboard. There’s a secret to encrypting the key, but I’m not going to go into detail about that here. I cover much more about keys and the methods used to protect them in Chapter 7. Because this chapter is really about symmetric algorithms, that’s what I focus on now.

 Python   SQL   Java   php   Perl 
 game development   web development   internet   *nix   graphics   hardware 
 telecommunications   C++ 
 Flash   Active Directory   Windows