Cryptography

Crypto Basics

Computers and use of the Internet have fostered new interest in cryptography partly due to the new emphasis on personal privacy. Little did I realize that in our efforts to make it easy for computers to share stuff, it would make it easy for other people to see all of our personal stuff, too.

Cryptography can be used to

• scramble your files,
  
• prove who you are (and maybe who you aren’t!)
• alert you if the contents of a file have been changed,
  
• attest to the identity of the person who sent you a message,
• keep online communications safe and secure, and,
  
• of course, hide important data.
  

And the best news of all is that not every cryptographic solution is expensive, and you don’t need to be a rocket scientist to incorporate crypto solutions into your network.

The algorithms we use today have been tested by crypto experts to check their strength, but sometimes it takes years to find the fatal flaw. When this happens, notices are sent out via vendors and the media to let users know that they may need to make some changes in encryption programs they are using.
Most algorithms are mind-numbingly complex mathematical equations — or at least they appear that way to me! Fortunately, you normally don’t have to deal with the algorithm itself — the encryption software does that for you.
There are tons of different algorithms used in the world of cryptography. Why? For the same reason you use different recipes to make a cake. Some recipes are better, some recipes are easier, and some recipes depend on time and care to make them turn out right. The same thing happens with algorithms — we need to use faster, easier, stronger algorithms, and some are better than others at accomplishing the task. It all depends on your needs as to which algorithms you’ll eventually use in your system.



Getting to Know the Basic Terms

• Encrypt: Scrambling data to make it unrecognizable
• Decrypt: Unscrambling data to its original format
• Cipher: Another word for algorithm
• Key: A complex sequence of alpha-numeric characters, produced by the algorithm, that allows you to scramble and unscramble data
• Plaintext: Decrypted or unencrypted data (it doesn’t have to be text only)
• Ciphertext: Data that has been encrypted
  

Breaking Ciphers
One big problem with ancient ciphers is that they were easily figured out, and the secret messages weren’t secret for very long. As cryptography got more complex, the secret messages stayed secret for a longer period.

The Enigma (WWII war) machine took several years to break and it was finally cracked through a combination of eavesdropping, engineering, pattern recognition, human laziness (on the German side), and some sheer luck. The Enigma team listened and heard clacking and clicking, which told them they were dealing with a machine, and then they managed to make a duplicate machine themselves (and got it right with luck). They noticed that some messages started with the same grouping of letters and were very lucky that the Germans used the same phrases many times to synchronize remote machines.



Not-so-secret keys
If you leave the keys to your car in the ignition and the doors unlocked, what do you think the chances are that it will be stolen soon? (If it’s a new Mercedes SL55 AMG valued at over $110,000, I’d say the chances are pretty good that it would be gone by morning.) The point is, if you leave the keys where other people can find them, you’re the one to blame. One of the biggest weaknesses in cryptography has been the poor use or sharing of keys. Like your password, you don’t write it on a sticky note and put it on your monitor. (Do people still do that?)



The art of cryptanalysis
Cryptanalysis is the art of breaking ciphers, and the National Security Agency (NSA) is renowned as one of the world’s largest employers of cryptanalysts.

The CIA is also very into crypto (which makes sense, as they are the home of spy versus spy), and they have a crypto challenge for anyone who wants to give it a try. When the new CIA headquarters was built in 1990, a sculpture called “Kryptos” was installed in front of the main entrance. The sculpture is an encrypted message. Part of the code has been cracked, but the man who got it spent more than 400 hours on it before he even got close to cracking just the first part. He finally managed all but the last 97 characters. If you want to give it a try, visit here.

Key-length is mentioned a lot in books and articles about cryptography. That’s because the longer the key (drum roll, please), the harder it is to guess what the key is! Even if the keys weren’t already common knowledge, they still wouldn’t take long to guess. You could probably even do it with plain old paper and pencil.
The job of keeping keys a secret has been one that has plagued us for centuries. You have to share the key at some point in some manner, or the recipient won’t be able to decipher the message.



Known plaintext
If you know for certain both a plaintext word and its ciphertext mate in a message, it can make cracking the message a piece of cake. For example, if you look at an encrypted message with a string of characters like XROL and you know that it means CAKE, you can go through the entire message substituting all the Xs with Cs, Rs with As, and so on. If nothing else, it can certainly give you a clue as to what the words might be. It’s kind of like playing Wheel of Fortune. If you play around with these variations long enough, you might just discover the key for the entire message.



Pattern recognition
The first thing you look for when you’re trying to break a code is a pattern in the encrypted message. For example, the letter E is the most commonly used letter in the English language, so you look for a letter in the message that is used more than any of the others. That may indicate that that particular letter is actually the letter E. Failing that, the second most common letter in the English language is the letter T.
Finding a pattern was part of the solution for the man who has partially cracked the Kryptos sculpture at the CIA headquarters building (which I talk about a couple sections back). He looked long and hard for a grouping of letters that would correspond to the word the. Because the is extremely common in the English language, it’s usually a safe bet to start there, and many cryptanalysts do.



What a brute!
If you’ve failed to decrypt a secret message by trying to figure out the key or by looking for patterns, you might just try banging your head against the wall. Brute force might just work.

I’m kind of joking and kind of not when I list brute force as a method of breaking an encrypted message or file. Actually it’s done quite often thanks to computers getting faster and the ability of linking computers together for strength and will power. In some cases, computers working in parallel can be more powerful than one of the most powerful computers used by the NSA.

Brute force is a trial and error method of trying every possible combination of characters against the encrypted data in an attempt to discover the key. That’s one of the reasons I always stress that you use the longest keys possible. For example, a 56-bit key has 256 possible keys. That’s more than 72 quadrillion keys that must potentially be tried in order to find the correct one. You might think that, given those numbers, a 56-bit key would be pretty safe then. Wrong. In 1997, a distributed computing effort cracked the RSA’s 56-bit RC5 encryption in less than 250 days. One of the more famous brute force cracks was that of the DES algorithm. Many people didn’t think it was possible to crack DES by using brute force, and everyone in the crypto world was talking about it when it happened.



Cryptosystems
By definition, a cryptosystem is the combination of three elements:

• the encryption engine,
  
• keying information, and
  
• operational procedures for their secure use.
  

In other words, almost every encryption program can be considered a cryptosystem because it has everything together in one package. The encryption engine is the part of the software that starts the encryption with the selected algorithm, and the keying system is the portion of the software that creates (and sometimes manages) the keys needed to encrypt and decrypt data. The operational procedures are how all of these parts interact and how the output, or result, is formatted and what file extension (if any) is used. So, almost every encryption product you buy off the shelf is, in a sense, a cryptosystem.

Some people may argue that a cryptosystem is the complete infrastructure of encryption programs, hardware, and network connections, but I’ll stick to the more traditional definition.

Many of the self programs include more than one algorithm for you to use for encryption. Usually these programs give you a one type of algorithm — such as symmetric or asymmetric algorithms — for you to decide upon. Sometimes you’ll see a drop-down list of the algorithms for use, or there will be a configuration setting in which you choose which you care to use. The differences between the algorithms come in two types:

• symmetric, which means one key is used,and
  
• asymmetric, which means two keys are used.

Because symmetric algorithms work much faster than asymmetric algorithms , some cryptosystems use both types in their software package. This is referred to as hybrid cryptosystems. Usually with this type of system asymmetric algorithms are used to exchange two keys between sender and recipient, and a symmetric algorithm actually does the encryption.



Everyday Uses of Encryption
There are a lot of ways that you deal with some form of encryption every day. As businesses now rely heavily on the Internet and other forms of networks to buy, sell, organize, inform, provide services, and form alliances, they also have to deal with the fact that sometimes these networks are transmitting very sensitive data. Some businesses decide on their own that protection of this data is a good thing, and others have either learn that through bad experiences or have to comply with new laws that deal with the protection of personal data.

Computers have become so insidious that many of us don’t even realize sometimes that we are interacting with them. Most of these systems are encrypting the data as it goes across the wires. Have you used your debit card to buy gas at an automatic pump lately? Read on for some other examples of everyday encryption.



Network logons and passwords
When you log on to a network, either at home or at work, you are normally asked for your UserID (or User Name) and your password. When PCs first appeared, they didn’t have the capability of networking, so there was no need for such security. But when networking software became generally available, businesses especially realized the need to keep unauthorized users off the networks and to compartmentalize which sections of a network the staff were allowed to roam. Hence, the UserID and password was the logical choice for controlling access.

Because there were (and are) various networking applications, not all the logon procedures were developed the same way. It’s the same old story — all the vendors make their own version of networking, hoping that theirs will become the standard. Alas, we run into something very common in computing and networking, and that is applying the lowest common denominator in order to achieve interoperability.

At first, passwords were passed from the user’s computer to the server in plaintext. Definitely not a good idea, but who would have thought that people would want to do harm with computers? Some sort of encryption had to be used to protect the passwords, so each of the vendors developed their own algorithms or hashes for accomplishing this task. The first encryption hashes were pretty dismal and could easily be cracked. To make a long story short, password encryption got better, but some elements of the older, crackable hashes had to be included for backward compatibility and other interoperability issues.

The remaining bad apple in the batch is called LANMAN, which stands for Local Area Network Manager. LANMAN is a method of storing your password that Microsoft included so that your password could be exchanged with other non-Microsoft networks such as Novell. The trouble with LANMAN is the way that it is encrypted and stored on the computers. To be frank, it’s the worst password encryption method I’ve ever seen — the passwords can be cracked in less time than it takes to blink an eye. Here’s how the LANMAN encrypts and stores passwords:

• Passwords are converted to all uppercase characters.
• Password length is a maximum of 14 characters. If your password is longer than 14 characters, LANMAN shortens it. If your password is less than 14 characters, LANMAN “pads” it with extra character.
• When LANMAN “pads” a short password with extra characters, those extra characters are always the same characters, no matter what the original password is.
• The password is split into two, seven-character pieces.
  

1. So first of all, LANMAN breaks the rule of using upper- and lowercase characters in your password by changing all the characters to uppercase. For example, if your password was cATclaW, LANMAN stores it as CATCLAW.
   
2. Secondly, because the next set of seven characters is always the same set of characters, hackers know they can just throw that portion away and concentrate on the first seven characters.
   
3. Thirdly, the algorithm that Windows uses to encrypt the character is extremely weak and any password cracker worth its salt can crack them in no time.
4. Windows, by default, stores your password both in the LANMAN method and a stronger encryption method. Hackers don’t have to bother much with the stronger stored version since the LANMAN is so easily cracked.
   

Although most Windows networks no longer have a need for LANMAN support, Windows still stores LM password hashes (also known as LANMAN hashes) by default on Windows NT, 2000 and XP systems (but not in Windows 2003). There is an article on Microsoft’s support site on how to disable LANMAN which can be found here.
If your system has LANMAN enabled and you don’t absolutely need it, please disable it soon!



Secure Web transactions
The odds are in your favor that if you’ve ever purchased something from an online shop with your Web browser, you’ve interacted with at least one form of encryption. In fact, you should ensure that any shop you order from is using at least 128-bit encryption because otherwise, all of your personal information is probably not being protected — or at least not being protected to the fullest extent possible.

As I mention earlier, having your credit card number and personal data travel across the wires in the cleat is not a good thing! However, prior to 1995, there was no technology in place to ensure secure Web transactions. All personal data was sent in the clear, and you couldn’t even verify who you were really sending that data to. Because it’s very easy to hijack a transaction between your computer and a Web site without you even realizing it, you could be sending your credit card number to an imposter and you’d have no idea it happened. In order to correct the problem of the Web sending and receiving data in the clear, some fixing had to be done to the HTTP protocol that handles the sending and receiving of data. S-HTTP (Secure HTTP) was created so messages and files could be sent encrypted. S-HTTP doesn’t actually provide the encryption; it just makes it possible for encryption to be added on. But vendors competing against each other again resulted in the fact that not all Web browsers and servers can use S-HTTP. There go those standards again. . . .

Another fix created to solve the security problem was the creation of SSL (Secure Sockets Layer). SSL is designed to allow a secure connection between your browser and a Web server, and all data that travels between the two can be encrypted, not just individual messages like S-HTTP. Again, SSL doesn’t actually provide the encryption; it just makes it possible for encryption to be used. SSL has become sort of a de-facto standard, and all Web browsers and servers are capable of using it. There are two levels of encryption available: 40-bit and 128-bit. The bit is the size of the key and, — and I’ll keep harping about this — the longer the key, the better the security.
SSL and S-HTTP have very different designs and goals, so it is possible to use the two protocols together — and some merchants and banks do use both. You’ll know when a secure connection has been established when a small key or lock appears in your browser’s status bar and the URL has changed to “https” instead of just plain “http.”

We must also examining Web site certificates to check that they are authentic to verify a merchant or bank’s identity.



ATMs
Ahhhhh, what would I do without ATMs nowadays? It’s wonderful to be able to go downtown or travel overseas and not have to worry about stacks of bills in your wallet. No need to rob a bank; just stick your card in the hole in the wall, and the machine makes money on demand for you (or at least it seems that way).
A lot of famous stories and movies are about big bank robberies, and people seem to always cheer when the crafty robber gets away will millions and lives happily ever after. But, hey! That was your money the robber stole, too! Obviously, security is a big issue here. Banks have had to add much more physical security to their ATMs in the past few years, but they are also pretty good at keeping up on the back-end security through the use of encryption.

The magnetic strip on the back of your ATM card contains a wealth of information that is picked up by the bank’s computers when you slide your card into the slot (or in a merchant’s point-of-sale machine). One of the bits of data on the strip is your account number, encrypted of course. When you enter your PIN, an encryption key is compared to an encrypted account number to see if they match. If they do, you’re in luck. Punch in the wrong PIN too many times and the machine slurps up your card.

But just because your bank utilizes encryption when handling transactions, don’t be lulled into a false sense of security. The implementation of encryption has to be good or the security can be breached. In 2001, two university student researchers in England found a huge hole in the way most systems were handling encryption of the account number. It wasn’t the banks’ fault — the vendor who sold them the systems for handling their ATM transactions had goofed. It turned out that the first four digits of the account number were always sent in the clear! The students used this information to eventually get the 3DES key used for encryption, and they were able to demonstrate that they could then crack up to 7,000 PINs per hour. This didn’t get too much media coverage in the United States, but luckily the amount of press this was getting overseas forced the computer vendor to come up with a fix for the system.



Music and DVDs
If you haven’t heard of the DMCA (Digital Millennium Copyright Act of 1998), then you probably don’t get into copying DVD movies or downloading music from the Internet. I don’t want to get started on whether the DMCA is a good thing or not — that’s a huge and contentious issue in itself and doesn’t really have anything to do with cryptography except that the DMCA allows film and music companies to protect their copyrights with encryption.

Each DVD player sold has a computer chip in it that contains a decryption key so it can read the encrypted portion of a DVD disc. The computer chip is also contains a country code that matches where the DVD player will be sold and used (assumedly, in any case). When the DVD discs are made, a section of the disc is encrypted by the music industry’s proprietary system called CSS (Content Scrambling System). This system encrypts part of the disc with a country code — sort of like the country codes for the telephone system. One code is used for North America, another for the South Pacific, and so on. Now comes the fun part. If you buy your DVD player in Japan and try to play a DVD bought in America, the disc won’t play. That’s because CSS is an access control system that prevents the playback of discs on players that don’t have the decryption keys that the movie industry provides to authorized manufacturers. Many, many people don’t know this and have found out the hard way when they try to play the movie they bought while vacationing in England or somewhere other than the United States. There’s a young man in Norway who owned some DVD movies and wanted to watch them on a computer he built, but the computer did not have the ability to read the encrypted code on the DVD discs. So, he wrote a program he called DeCSS and installed it on his computer. It worked! He could now watch his movies on his computer. The young man was so pleased with it, he put it on the Internet to distribute for free. That was probably his first big mistake.

Part of the DMCA says that the manufacturing of or trafficking in technologies capable of circumventing technical protection measures used to restrict access to copyrighted works is highly illegal.

Well, the young man did circumvent the technical protection on DVD discs, and he made it available for distribution. The guy has been tried and acquited for this crime once, but it looks like another trial may be coming up soon. I’m not arguing who’s right or who’s wrong here; I just wanted you to be aware of the fact that sometimes the use of cryptography gets just a little bit sticky.



Communication devices
Until about 10 years ago, everything you said over a cell phone could be picked up and listened to over a simple, inexpensive Radio Shack radio scanner. There were huge scandals in the UK when tapes of Princess Di’s cell phone conversations were released to the tabloid press. It seems a lot of people like to eavesdrop on others’ conversations. Even Newt Gingrich was stung when his cell phone conversations showed up in the press.

The majority of cell phones in America have their phone numbers and voice transmissions encrypted, but only to a certain point (2006). The part of the call between the cell phone and the tower is encrypted, but as soon as the conversation reaches your provider’s gateway to the land-line phone system, it’s decrypted. That’s right, all land-line telephone communications (with the exception of government and military systems) are unencrypted. If you know how and where to place a gator clip and a phone receiver, you can listen in on anyone’s phone calls.

The GSM (Groupe Speciale Mobile) wireless phone is the standard in Europe and is the world’s most widely used cellular technology. More than 215 million digital phones use it worldwide, including more than 100 million in Europe and 5 million in the United States (2006). GSM transmissions are encrypted, but the A5/1 algorithm keys, which are used to scramble and unscramble the data, are much shorter than advertised and thus much easier to break.



Why Encryption Isn’t More Commonplace
Until fairly recently, it was unlawful for average American citizens to even own encryption technology. That was the realm of the NSA, and all encryption products were tightly controlled. In the early 1990s, a number of privacy activists and cryptographers helped loosen the restrictions on who could own encryption, and the courts have since ruled that we have the right to privacy in our communications and storage of our own data.

Given that our right to own and use encryption is so new, it’s not surprising that not many people know much about it. Now the market is burgeoning with new products and encryption technologies, which makes it even more difficult for people to decide what to buy and implement — if they decide on encryption at all! However, some states are passing laws stating that companies that store personal information need to use cryptography to protect that information. It’s likely that we will see a wave a new laws like these over the next five years (from 2006).

Another thought that comes to mind is the Internet. Again, until recently, we trusted the Internet and saw no need to protect ourselves. But with hacking and identity theft becoming more common, it makes sense to start looking at ways to protect ourselves and our information.



Difficulty in understanding the technology
By and large, encryption programs have suffered from a lack of intuitive interfaces — if people don’t understand how to use the software, they won’t use it. Period. This is the fault of the developers. They seem to have forgotten that cryptography is new to most users.

The graphical interface to many encryption programs was almost indecipherable, even to people like me who know what they are doing. It’s no wonder then that people who have bought encryption products have never gotten around to use them. They don’t know how to work the commands and menus.

Another reason people find cryptography so hard to understand is that the creators of cryptosystems — usually mathematicians — are the same ones who have written most of the textbooks explaining the subjects. Now, I don’t want aeronautical engineers explaining to me how a plane flies because I won’t understand what they are saying. For that same reason, I don’t want a mathematician to explain to me how to encrypt my e-mail. Because of this I have taken the non-mathematical route to explaining how cryptography works.

Luckily, things are changing in the world of cryptography. User interfaces for encryption products are becoming easier to use, and publishers are seeing the need for easy-to-understand docs (like this one) for these products. The vendors themselves are also helping by putting large amounts of “How-To” information on their Web sites with FAQs (Frequently Asked Questions) to help you find the answer to your problem.
You can’t do it alone.

One of the biggest problems with cryptography is that you can’t do it alone! You need at least two people — a sender and a receiver. Otherwise, the encrypted files or messages just sit there. It’s sort of like when the first video phones appeared — there was no sense in buying one for yourself if you didn’t have anyone to call who had one, too. What’s the point in showing your face on the telephone line if there’s no one on the other side to see it? If you’re going to be receiving encrypted files and messages, you need to have the same software, or compatible software, as the sender. That’s simple common sense. Likewise, if you are sending encrypted files or messages, you need to be sure that the people on the receiving end have some means of decrypting what you’ve sent. Luckily, many products operate on similar standards and can be made to work with similar products. It may take a bit of trial and error to get it working correctly, but the good news is that you usually have to do that only once.



Sharing those ugly secrets
If I ask you to water my houseplants while I’m on vacation, you’ll obviously need the key to get into the house. If I don’t have the opportunity to hand you the key in person, I’ll have to hide it somewhere and then let you know where it is. I can’t leave a message on the front door — that would be too easy for someone else to intercept. I shouldn’t put the key under the door mat because that’s usually the first place a thief looks. I could call you on the phone and tell you the location of the key, but how do I know that I’m really talking to you?

That last scenario may be a bit far-fetched, but I’m sure you can see my point by now. How do you share a secret without letting the whole world know? That, in a nutshell, is the largest problem facing cryptography — how do you safely and securely share the keys? There are tons and tons of papers and books covering this subject alone. It’s safe to say that modern cryptography products do have ways of safely sharing the keys, but it takes some effort and common sense on the users’ part, too.



Cost may be a factor
Although there are free crypto products available for use, few of them are suitable for a business environment. Then, as with all business decisions, whether or not to employ cryptography comes down to the question of how much it will cost. As I mention earlier, you can’t do it alone, so you also have to make sure that your solution will interoperate with what your partners and customers are using.
In addition to the cost of the crypto products themselves, you also have to take into account the man-hours spent just coming to a decision. There’s a lot of research to do (much of which I help you with), and you may need to add servers and sub-nets to your existing network. There is time and money involved in the setup and configuration of the system, the training of users, and personnel to handle maintenance of the system.

This may seem like an overwhelming task at first, but I help you break it down so you can make a decision that you can ultimately afford. When it comes to crypto products, newer is not necessarily better. The last thing you want to do is to buy crypto products solely based on their “gee-whiz” appeal.

Special administration requirements
Crypto products require special handling, which means that you need to have experienced staff to operate and maintain the systems. This is not something the accountant can do as an adjunct to his or her normal duties; you need a skilled professional. Why? Because if your crypto systems are not set up and maintained correctly, you run the risk of exposing all of your secrets. In addition, your staff will lose their keys and forget their passphrases, and new users need to be added to the system and trained on its use. If you’re trying to increase the security of your system and protect your company’s assets, you might as well do the job as well as you can. In this case, “good enough” sometimes isn’t enough.

You’ll find information on identifying your requirements, deciding what you need, and telling good products from bad products in the following go on. I also give you sneak peeks into various products you may encounter, and I give you a really good description of that incredibly elusive beast, PKI (Public Key Infrastructure). Now let the journey begin.

Major League Algorithms

• Telling the bad crypto from the good
• Looking at symmetric keys
• Delving into symmetric algorithms
• Discovering how asymmetric algorithms work
• Brief descriptions of the most commonly used algorithms

Over the decades, many agencies, companies, and individuals developed more and more sophisticated algorithms. Of course they also developed more complex keys to go with those algorithms so the secret messages could be decrypted so easily. In every case, whether the algorithm was made public or not, someone figured out the algorithm and published the results. It turned out that it is relatively easy (for cryptanalysts or very experienced programmers, that is) to crack algorithms. The algorithms can be reverse engineered, and the internal workings can be made known.

In 1987, RSA Data Security developed an algorithm called RC4. They had cryptanalysts test it, and the tests proved that RC4 was a good algorithm. Now, instead of publishing the algorithm, RSA decided to keep the inner workings of RC4 to themselves in the hope that they could license it and make money off the algorithm itself. In 1994, the inner workings of RC4 mysteriously appeared on the Internet for all the world to see. Because the secret was out, RSA could no longer sell the algorithm, and it was back to the drawing board for them.

What the RSA/RC4 example proves is that the internal workings of an algorithm are always discovered. Talented people can reverse-engineer software that uses an algorithm. Even if the entire workings are not immediately evident, cryptanalysts can make some very educated guesses. Well, if that is true, how do you keep the data safe if everyone knows how it’s done? The solution is in the key. The key to unlocking the algorithm, that is. If you can keep the key unknown and unknowable, that goes a very long way in keeping the data safe from prying eyes. Look at it this way: We all know how the lock on a door works. There are a series of small round bars called tumblers that, when lined up correctly, drop out of the way, removing the obstruction, so you can turn the key and open the door. But, just because you know how a door lock works does not mean that you can find the right key. (I’m not talking about locksmiths and burglars; I’m talking about average folk here.) It takes a lot of time and trouble to find the correct key. Yes, that is a simplistic view, but I think you get the point.

In modern cryptography, the developers of algorithms are quite happy to release information on how the algorithm works because they have created new ways of making stronger keys. Keys nowadays are made from very long prime numbers and the longer the key, the better the security. (Prime numbers can be divided only by the number 1 and the number itself. For example, 7 is a prime number.) In addition, some keys are also encrypted themselves. So, even if you find the key, you have to figure out how to decrypt it. It’s important to know, too, that the keys are just data files, so they look just like the rest of the encrypted data. It takes a degree of skill to be able to recognize a key and separate it from the rest of the message or file.



Beware of “Snake Oil”
In most software and hardware markets, the latest and greatest product is the one that everyone wants. In the world of cryptography, almost the exact opposite is true — nothing new is trusted until it has been extensively tested by the outside world.
Snake oil refers to any crypto product that vendors oversell as a cure-all. It harkens back to the frontier days when pharmacists and traveling salesmen sold products of a dubious nature that were supposed to cure everything. They wouldn’t tell you exactly what was in it, but they assured you that it worked.

Cryptographic software and hardware has sometimes been sold the same way. The makers of this magic stuff all assure you that it works in “new and previously untried ways.” The salespeople will make promise after promise of all the wondrous things the software is capable of, but will not be able to provide you with one verifiable test that upholds their claims. Nor will they give you any technical data on the inner workings of their product. These things should be enormous red flags to potential buyers. If you can’t get hard data on how a cryptosystem works, it’s very likely to be snake oil. Buy it and you will get bit by the snake.

Here are some things you should look out for when reviewing cryptosystems for signs of snake oil:

• The marketing literature and technical literature are full of technobabble. If you can’t make sense of what is being said, how can you expect to be able to implement it? Run it by your IT Department to see if they can make sense of the hype. These types of cryptosystems are trying to baffle you into thinking they are brilliant.
• The company tells you that the algorithm is unbreakable. Believe me when I tell you that every algorithm is breakable. It may take 100 years or 10,000 years, but someone will find a way of breaking the algorithm.
• They claim that their product uses military-strength encryption. Do you really think that the military would tell the general public which algorithms they use? Exactly how safe would the military’s secret be if every terrorist group in the world knew what they were using? Of course, some sales people confuse the term “military strength” with the fact that the encryption has been reviewed by the military. Just because the encryption has been reviewed by the military (or the NSA) does not necessarily equal military strength.They claim to use secret algorithms. That’s right up there with “military- strength” encryption as a red flag indicating snake oil.

  All the crypto experts will tell you that for an algorithm to be determined good, it has to be tested by people who had nothing to do with the development of the algorithm. It’s a commonly known fact that writers can’t see their own typographical errors — that’s why there are editors. In the same vein, developers of algorithms can’t see their own errors, and it takes an outside expert to discover them. There are scores of mathematicians who are ready, willing, and able to test algorithms. Some of them even do it for a living.

• The claim that You don’t need to know what the product is doing or the Trust Us plea is a good indication of snake oil. This usually means that either the vendor doesn’t know how the product works or they are just lying to you.
• The claim that the algorithm has been tested by hackers is totally bogus. Excuse me, but hackers don’t know much about algorithms; they know operating systems, network protocols, software, and programming. This does not make them experts in cryptography.
• They claim that experts evaluated their product and found it safe or strong. If a vendor is using experts, they won’t mind listing the papers the experts have written. These papers are often used to establish who is an expert and who is not. Chances are that if you’ve never heard of the expert and the expert has never been published, that person is not an accepted expert on the subject.
• The claim that the software and/or algorithm are exportable from the U.S. is also a red flag. For those who are not aware of it, the U.S. government restricts the export of strong encryption to many foreign countries. If the encryption used in the product you are considering is “export strength,” it could mean that it’s not very strong (like only 40-bit encryption). If the encryption is “strong” and the vendor states that it is “exportable,” that could also mean that you may have to comply with a number of government rules and regulations concerning its export.
  

You should take all encryption products’ marketing literature with a grain of salt. They are all in the market to make money. You should look at their list of claims and compare them to the snake oil flags listed above. If the marketing brochure contains only one of the claims above, it could well be that the marketing staff is clueless about encryption products. On the other hand, if the marketing brochure lists many of the points mentioned above, the chances are pretty great that you are dealing with snake oil.

Although cryptography and encryption techniques and algorithms are complex subjects, the software and hardware vendors are attempting to sell their products to non-experts. For that reason alone, the vendors should have materials that explain what their products do and how they do it in simple terms that the average user can understand. If you can’t understand what the vendor is talking about, ask to see their installation guidelines or their user guides. You have to be able to understand how to install and implement a system in order to use it correctly. If you mess up the installation and implementation, the encryption will be flawed, which is almost as bad as not having encryption because it gives you a false sense of security.
As for the “new” algorithms, certainly there are new algorithms being created on a constant basis, but there are also many very good algorithms that have been widely tested and are freely available. You can get the source code for these algorithms for free at most university Web sites and other sites dedicated to cryptography. In this case, it’s better to chose the devil you know over the devil you don’t. There are always forums and newsgroups on the Internet dedicated to cryptography who are very good at steering newbies in the right direction.

But, enough of the bad news, let’s get on with the good news: encryption techniques and algorithms that work!



Symmetric Keys Are All the Same
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. By the way, if a vendor tells you that their product reuses the key table, that’s a bad thing!



Protecting the Key
Now that you’ve created a long, strong key with which to encrypt your data, how 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.



Symmetric Algorithms Come in Different Flavors
Although symmetric algorithms all use one key to encrypt data and the same key to decrypt data, that doesn’t mean they all work the same. There are quite a few flavors of symmetric algorithms:

• IDEA,
  
• Twofish,
  
• DES,
  
• 3DES, and
  
• AES
  

I go through the commonly used symmetric algorithms and explain their similarities and differences.



Making a hash of it
Not all algorithms are meant to be decrypted. Huh? That’s right — some algorithms are used to encrypt data, but not to decrypt them. Such is the case with a message digest, which is also known as a hash. I’m not sure if “hash” is a nickname the algorithm got because it “hashes up” the message, but it certainly seems logical. The most commonly used hashes are SHA-1 (pronounced shaw-one) and MD5. Hashes are not truly symmetric algorithms because the encryption works only one way. The end result — the encrypted data — is never meant to be decrypted. Instead, the end result is used sort of like a unique serial number. I include hashes in this section because the output is like a symmetric key.

Hashes take a message and pad it a bit by adding some extra data to the message. The hash then encrypts the message and uses a finite number of bytes from the encrypted portion to be used as a snapshot or fingerprint of the data. Hashes are used to prove that the data that has been transmitted is same as the original data and that nothing has been changed en route. How can it do that? Well, every time you use a hash algorithm on the same data, you’ll get exactly the same result. On the other hand, if the data has been changed, even by one letter or a single space, the hash will change.

Hashes are useful in ensuring that the software you download from the Web is the same software that the vendor released. It has not been uncommon for hackers to get the source code of software, insert a back door or a Trojan program, and then place it back on the Web for downloading. If you were to compute the hash for the altered software, it would not match the hash that the vendor made from the original software. In this way, hashes are used as protection mechanisms. You may want to consider for checking the integrity of data kept in storage and messages that can be used as evidence in court.



Defining blocks and streams
Block and stream ciphers are important subsets of symmetric algorithms. I’m not talking about walking around the block or paddling down a stream; I’m talking about the mechanisms of how the symmetric algorithms go about encrypting the data.
Block ciphers take exact chunks of data, encrypt them with the key table, and then take the next chunk, and so on. You can think of it as being a digital bucket brigade.

In this type of brigade, however, every bucket must contain exactly the same amount of data. If a bucket is short and doesn’t have the correct amount of data, the algorithm drops a bunch of bits in the bucket to even out the amount. The algorithm knows what was used to fill up that bucket, so it can throw those bits away when the decryption process begins.

There is a weakness in block ciphers, though. If two different chunks of data contain the exact same data, the ciphertext could be exactly the same. It’s entirely possible that a statement or string of characters are repeated throughout a document, (like the name of a company or a product name) so block cipher algorithms had to be changed to fix this problem. They do that by starting with an initialization vector (IV). And what exactly is an initialization vector? It’s more random stuff! In one sense, an IV is similar to the seed data that is added to a PRNG. However, not every algorithm or encryption product uses the same method for creating an IV. Some systems can take random input from the computer’s memory buffer and add that to the chunk of data to be encrypted. There have been some products that have been found to have flawed IVs; that is, they used the same string of data all the time instead of takings something random from the computer. To make you feel more at ease, I can tell you that this flaw is usually quickly exposed and the method of creating an IV is changed.

But we’re not finished yet with the encryption process for a block cipher. In order to further obfuscate the ciphertext, the block ciphers currently in use create multiple loops of encryption called cipher block chaining (CBC). In a nutshell, here’s how the whole thing works:

1. The algorithm creates some random data called an initialization vector (IV).
2. The IV is XOR’d with the first chunk of data. (XOR-ing is a bit-by-bit comparison)
3. The XOR’d data is encrypted with an entry from the key table.
4. The encrypted data is XOR’d with the next chunk of data.
5. The XOR’d data is encrypted with an entry from the key table.
6. Repeat Steps 4 and 5 over and over until the entire data file has been encrypted.
   

And there you have a block cipher that includes an IV and CBC.

Now we go on to stream ciphers. If you go back to my original analogy of a bucket brigade, you can think of stream ciphers as the full rush of water coming out of the fire hose. The difference is that instead of encrypting each bucket as it comes through, you encrypt each drop of water as it comes out of the hose. It may seem impossible, but modern computers (2006) have little trouble handling this type of speed. Here is a short example of how a stream cipher does its tricks:

1. Generate a key to create a key stream (a very long key of random data that is at least as long, or longer, than the plaintext).
2. Grab one byte of plaintext and grab one byte of key stream.
3. Encrypt the plaintext with the key stream to create the ciphertext.
4. Start over from Step 2 and continue through Step 3 until all the data is encrypted.
   

As you can see, a stream cipher is quite a bit different from a block cipher. In one sense, the key stream can be considered the same as a one-time pad. As long as the pad (the key stream) is used only once, the encrypted data is secure. However, if the plaintext is longer than the key stream, then the algorithm will either have to create a new key stream or use the existing key stream again. After that key stream is repeated, the encryption becomes much weaker. Reusing the key stream makes it easier for an attacker to discover the key and may ultimately crack the encrypted data.



Which is better: Block or stream?
The simple answer to this question depends on what you need the encryption for. Stream ciphers are very simple to program and they process very quickly. The most commonly used stream cipher is RC4, which is used in SSL (Secure Sockets Layer in secure Web transactions). To date, that is the only stream cipher that has become a de facto standard.

I mention the possibility of a stream cipher having to use its key stream more than one time. This is a weakness and therefore you shouldn’t use a stream cipher if you have a lot of data to encrypt; that is, unless you are willing to have the process interrupted to re-key every time the algorithm reaches the end of a key stream. This takes time and processing power, too. The only system I’m aware of that has overcome this problem is the secure telephone unit used by the government and the military for secret communications. This particular phone is called a STU-III (Secure Telephone Unit #3). It uses a stream cipher because it is easier to change a conversation into a continuous digital stream and mix the digital conversation with a stream cipher. Because there is no way of telling how long a conversation might last, the STU-III constantly remixes the stream cipher as it encrypts the voice transmissions. Listening to the encrypted conversations on these systems is a hoot because it makes everyone sound like Donald Duck on helium speaking some alien language.

Block ciphers are slower to process but more block ciphers have become standards than have stream ciphers. Take almost any encryption program available and you’ll discover that they are set to accept DES, 3DES, and AES. That’s because those ciphers are accepted standards. If you are concerned about interoperability with other encryption programs, you’re better off using block ciphers.
If you need to reuse keys, a block cipher is better. That’s because the key table that is created by the algorithm can create a huge number of keys to use. There is very little likelihood that you would get the same bunch of random numbers to encrypt your data.

Neither cipher type is really “better” than the other; it’s more a question of meeting your encryption requirements.



Identifying Symmetric Algorithms

If you were to do a Web search on the term “symmetric algorithms,” you would discover that there are scores of symmetric algorithms. The main difference is that some of the algorithms have been extensively examined and tested by cryptanalysts and found to be good and others are not as well known or have not been heavily scrutinized. The algorithms that I mention here are considered standard and are commonly used by commercial encryption software. Of course you don’t have to go with the standards — you are free to create your own software with other algorithms. If you are using something new and untested by the cryptographic community, you could be compromising your security without even realizing it. For that reason, I strongly advise you to stick with the algorithms that have become accepted standards.




DES
DES stands for Digital Encryption Standard and was created in 1975 with some assistance from the National Security Agency (NSA). In 1981, DES became an accepted standard and was widely used. DES is a block cipher that uses a 56-bit key to create the key table. Then it goes through the process of combining a key from the key table with the block of plaintext. After the key and the plaintext have been combined, DES goes through 16 more changes (called rounds) to thoroughly mix up the ciphertext. To decrypt the data, DES just goes through all the changes in reverse order.
Given that a 56-bit key has about 72 quadrillion different combinations of numbers, most people felt that DES would be secure for a very long time. What people failed to consider was that computers got faster and cheaper and that it wouldn’t cost very much to create a computer specifically to break DES. In 1999, DES was broken in less than 24 hours on a specially built computer.



Triple DES (3DES)
Many years before DES was broken, cryptographers began working on its replacement. It wasn’t that DES was badly flawed; it was that the crypto community could see the end coming and they wanted to be prepared. So Triple DES (also referred to as 3DES) was created. Because a lot of software and hardware was already coded with DES, it made sense to make changes to an algorithm that was already in use, rather than creating an entirely new one. In that way, many of the older products were able to upgrade to 3DES (or a very similar variant) without having to completely rebuild the hardware or software.

As its name implies, Triple DES does something three times more than normal DES. That triple threat comes from using three keys on each block of plaintext. Instead of using one 56-bit key from the key table, Triple DES encrypts the plaintext with the first key, encrypts that ciphertext with another 56-bit key, and then encrypts the ciphertext with another 56-bit key. That may seem like overkill, but it works. 3DES is also able to work with longer keys to make it more secure. The most commonly longer key lengths (at present 2006) are 112 bits and 168 bits.

In order to crack this algorithm you would need to figure out three separate keys. Not only that, but the ciphertext will decrypt only when all three correct keys are used and in the correct order. It might be possible to guess one key, but you’d never know if it was correct until you combine it with the other two keys. The number of permutations is outrageously high, and no one wants to spend that amount of time attacking something of unknown value. What if you went to all the trouble to find all three keys, in the correct order, only to find the data was an e-mail message reminding everyone that there was leftover birthday cake in the break area? A lot of effort spent on nothing, I’d say.



IDEA
IDEA stands for International Data Encryption Algorithm, and it’s most often seen as a component of PGP (Pretty Good Privacy), a popular e-mail encryption program. This algorithm starts out with a 128-bit key. It then breaks up the 128-bit key into a total of 56 subkeys. How it does this is to divide the original key into eight, 16-bit keys. Then the bits of the original 128-bit key are shifted 25 bits to the left (sort of like everyone in a baseball stadium moving over 25 seats to the left). Now that the original key has been shifted and remade, it’s cut up into eight 16-bit keys again. You keep shifting and cutting up until you have a total of 52 keys, each of them 16 bits in size.

Believe it or not, with all of this switching and cutting, the IDEA algorithm is processed about three times faster than DES. One of the reasons it’s used is because it doesn’t create as much of a load on the CPU of the computer. But, because IDEA is newer than DES and 3DES, it has not really been accepted as a standard. It has been analyzed by the military, but they’re not saying what they’ve found. If there are any weaknesses in IDEA, no experts on the outside of the government have found them — yet.



AES
AES stands for Advanced Encryption Standard. Many expect this algorithm to be the heir apparent to DES and 3DES. It’s the first algorithm that was created through organized competition.
The contest was announced by NIST (National Institute of Standards and Technology) in 1997 in an attempt to find a good algorithm that would become the next government standard. In 1998, the list of competing algorithms had been whittled down to 15 candidates. Then the heavy duty testing began. The contestants began dropping like flies as weaknesses were found in most of the algorithms under consideration. By 1999, the cast of players had been cut to just five and another round of testing began. Late in 2000, NIST announced it had a winner — an algorithm called Rijndael (after Vincent Rijmen and Joan Daemen, pronounced rine-doll). It had survived all the tests, and people generally liked the way it worked. The government has called it their Advanced Encryption Standard (AES), but it isn’t quite the standard in the real world yet. Again, because it’s relatively new, there is some distrust and a feeling that it has not been tested enough for weaknesses. Regardless, there are products on the market that openly use AES and will continue to do so until it’s proven weak or breakable.



Asymmetric Keys

One of the biggest problems with symmetric key algorithms is that it is difficult to both share the key and protect it. Because you are using the same key to encrypt and decrypt the data, there’s no way around the fact that you have to share the key. Like the key to your front door, it’s possible for someone to steal the key or copy it.
Asymmetric keys take care of the problem of distributing keys by making two separate keys that are mathematically connected. You use a “private” key that you never reveal to anyone to decrypt the data you’ve received and the recipient uses their corresponding “public” key that everyone can have to encrypt the data. Actually, that explanation is a bit simplistic, but you get the idea. A similar idea is a bank safety deposit box. The bank has one key that they keep private, and they have a public key that they give to you. When you go to unlock your box to put your valuables in it, you need both the bank’s key and your key in the locks at the same time to be able to open the door to the box.

Asymmetric keys use prime numbers as their starting point. The first part of the process is to create a very large number by multiplying two very long prime numbers together. Now let’s say that you multiply two prime numbers together. If you multiply 5 x 7, you get 35. It’s not too hard to work backwards from the number 35 to figure out which two prime numbers were used to create it. But, if you used a number that was over 100 numerals long, how hard do you think it would be to find the two numbers that were used to create it? Go ahead and get your paper and pencil. I’ll wait.

You probably came up with the same answer I did: It takes an awfully long time! Even if you go through all this trouble, you have only one number. You still have a long way to go. From that long number, you derive a portion of it (via a mathematical computation) for the private key, and from the private key you derive a portion of it for the public key. The elegance in this process is that you can’t reverse engineer the public key and obtain the private key.
Although this private/public key concept is considered strong, you need at least a –2,304-bit key to achieve the same level of security of a 128-bit symmetric algorithm. Asymmetric algorithms are slow in processing and it is impractical to use them to encrypt large amounts of data. Symmetric algorithms can be approximately 1,000 times faster than asymmetric ones. Therefore, you usually see asymmetric algorithms used to protect small amounts of data such as e-mail messages and - small data files such as attachments to messages.




RSA
This is probably the most recognizable asymmetric algorithm, due in part to the very large corporation that stands behind it — RSA Data Security. RSA comes from the last names of the inventors, Ron Rivest, Adi Shamir, and Leonard Adleman, who created the algorithm in 1978. To date, it is the only asymmetric algorithm in widespread general use that is used for private/public key generation and encryption. Two other algorithms call ElGamel and Rabin also generate two keys and encrypt, but you don’t see them used as often as RSA. Because most of the other asymmetric algorithms generate only two keys, many programs use a combination of asymmetric algorithms and symmetric algorithms to protect data.

RSA uses prime numbers to create each of the keys (private & public), but using those keys to encrypt a large amount of data is impractical due to the amount of time it takes a computer to process the encryption. More often than not, an encryption program that uses RSA encrypts the data with a symmetric algorithm such as RC4 (or DES, or IDEA, and so on). Then the symmetric key created by RC4 is encrypted with the recipient’s public key. When the recipient gets the message, she uses her private key to decrypt the RC4 key, and when the RC4 key is decrypted, the bulk of the message can be decrypted.




Diffie-Hellman (& Merkle)
This algorithm is commonly known as DH, which represents the last names of two of the inventors. However, if you were to meet Whit Diffie or Martin Hellman, they would be sure to point out that they couldn’t have done what they did without the work of Ralph Merkle. It was only bad luck that Diffie and Hellman’s paper appeared in print before Merkle’s did, even though they all arrived at the same idea about the same time. So, out of respect for the authors, please remember Merkle.

There is one huge difference between RSA and DH in that the DH algorithm is not used for encryption. Huh? That’s right — DH is not an encryption algorithm; rather, it is a key exchange algorithm. Diffie, Hellman, and Merkle were more concerned with the problem of sharing a key over an insecure channel than they were about the encryption of data, so they came up with a solution that created a way to share a secret. Here’s how it works:

1. Natasha has a DH key pair consisting of a private key that she keeps to herself and a public key that she sends to Boris.
2. Boris receives Natasha’s public key and uses the DH algorithm to create a temporary private key and a temporary public key for himself. (Note that Boris’s keys have something in common with Natasha’s public key.)
3. Boris now takes his newly created private key and Natasha’s public key and has the DH algorithm generate a secret number.
4. Boris uses the secret number (instead of a RNG or a PRNG) to generate a key just for this transaction. This is called a session key.
5. Boris uses the session key to encrypt the data and sends it to Natasha along with his temporary public key.
6. When Natasha receives the encrypted message she can derive the session key because her keys and Boris’s keys have the same derivative — her public key.
7. With the session key pulled out of the message, Natasha can now decrypt the message.
   

Please note that when I say, “Natasha does this,” and “Boris does that,” I really mean that they are using their encryption program to carry out these actions. Natasha’s and Boris’s only real actions are to respond to any dialog boxes that pop up during the process. Of course the encryption program has the DH key exchange algorithm included in it, or none of this would be possible.



PGP
Let me say this from the start: PGP (Pretty Good Privacy) is not an encryption algorithm, although many people tend to think of it that way.PGP is a hybrid cryptosystem. It is most often used for e-mail because it has some very nice e-mail program plug-ins, but it can also be used for disk encryption and to securely erase data from a disk.

When a user encrypts plaintext with PGP, PGP first compresses the plaintext. Then it creates a session key, which is a one-time-only secret key. This session key encrypts the data. When the data is encrypted, the session key is then encrypted to the recipient’s public key. This public key-encrypted session key is transmitted along with the ciphertext to the recipient.



Elliptical Curve Cryptography
Elliptical Curve Cryptography, also known as ECC, is a very different form of asymmetric cryptography. It’s not used very much but when it is, it tends to be used to encrypt large amounts of data. That’s because ECC computes very quickly, and it doesn’t tie up a lot of processing time. ECC is also newer and not as well understood as some of the other encryption algorithms. For that reason, fewer researches have spent very much time trying to attack them to find their weaknesses. I am mentioning them here because I’ve begun to see secure data storage programs use ECC to encrypt the huge amounts of data that sits in large server farms.

ECC starts with a curve drawn on a graph. Remember your high school math projects where you had to draw a curve and then plot its x and y axes? Well, ECC starts out the same way. After the curves have been created, lines are drawn to intersect with the curves. The intersecting points on the curve are given numbers. Of course they are plotted numbers, so there are two: the x-coordinate and the y-coordinate. Now, add a bunch more dots to the graph as the seed, give them all numbers, and start adding and adding and adding all the numbers. The trick to ECC is that you have to know the shape of the original curve, the points where the lines intersect, and which point is the starting point for the addition to begin. From all of that you can create a large number and then compute a Diffie-Hellman key pair. ECC is simple enough to create, but it seems very difficult to attack.



Working Together
An issue with all algorithms is whether or not they are interoperable. The simple answer is that if you stick with the major algorithms, you won’t run into many problems. Almost all encryption programs come ready to use DES, 3DES, AES, and RSA. Fewer are able to handle DH key exchange and even fewer than that handle ECC. If you are going to be exchanging encrypted data with a partner, customer, friend, or significant other, it’s best to make sure that their programs are set up to use the same algorithms that your programs use. Not only do you have to worry about the interoperability or compatibility of the algorithms, but you also have to consider the file formats of the original data, too. For example, if you encrypt a graphics file as a .tif format and your partner can handle only postscript files, the decryption and viewing isn’t going to work correctly.

Interoperability becomes much more of an issue when you move into PKI (Public Key Infrastructure). PKI systems can be complex and expensive, and if you are using this type of system to authenticate users, customers, and partners, it’s very important that their systems and yours be able to talk to one another.

Deciding What You Really Need

You wouldn’t buy a car without first researching all the makes and models you were considering. Likewise, you wouldn’t buy a truck if what you really needed was an economical sub-compact. The same considerations should be made when deciding what cryptographic systems or programs you need to protect your data and communications. You’d think that it would be obvious to do a little homework before entrusting your security to a new system, but you’d be surprised at how often it’s considered just a necessary evil and the cheapest solution is considered good enough to do the job.

I want you to also remember that it’s not just the solutions you pick that will make your system work for you; it’s also the personnel you need to manage and maintain the system. You wouldn’t hire an inexperienced (albeit talented) teenager as a long-distance truck driver, and neither should you hire someone to manage your systems who has no practical experience in the field. Many systems require a certain amount of training of both administrators and users, so be sure to include that in your decision-making matrix.



Justifying the Costs to Management

Without a doubt, the most problematic area in almost any business is getting the management to approve the purchase. It doesn’t matter if you’re talking about office cubicles, copying machines, phone systems, or upgrades to the network. Whatever choices you give them, they always want to know if you can get the project done cheaper. It’s a fact of business life that you just have to deal with, so i give you some tips.

First of all, you have to look at the situation from management’s point of view. They have to make sure that the business shows a profit each year, and they may have a number of entities sitting in judgment of their business decisions — boards of directors, shareholders, and so on. This tends to make management very cautious, especially when dealing with a situation in which they feel insecure. How many managers do you know who really understand technology? So, in putting yourself in their shoes, you can often come up with persuasive arguments to make your case and covertly “teach” the technology to management so they can explain it to their higher-ups. In simple terms, management responds to decisions that make good money sense — something that will either save them money or make them more money. Start up your spreadsheets, and I’ll tell you which figures to start collecting.



Long-term versus short-term
Projects that will last a long time tend to pay for themselves over time. Consider solar-generated electricity for a home — it’s very expensive in the short term, but in the long term you can eventually kiss your power bills goodbye. Not only that, but a homeowner can and will have power if a bad storm knocks out the power grid, and in some cases might be able to sell his excess power back to the power company. This foresight and planning is good for everyone in the long run.

Short-term projects generally take only a short period of time to complete, and the investment results are more immediate than with long-term projects. There are no rules that state that one type of investment is better than the other, but there are pros and cons to each.

Unfortunately, in this age of cut-backs and low employment, many companies are concerned only with short-term solutions for their problems. What they forget to figure into their equations is that the short-term solution may not look so attractive in the long run. Take the company who decided to purchase cheap desktop PCs with limited expansion capabilities and low amounts of RAM. In the short-term, that purchase probably saved the company a lot of money. But in the long-term, it also cost them a lot of money to expand and upgrade their system as the company grew. What initially looked like a good return on their investment turned out to be a waste of good time and money.

The addition of cryptography to your network can be seen as either a long-term or a short-term investment, depending on the size and scope of the project. If you are setting up SSL certificates on your Web server to accept secure transactions, that may be seen as short-term because it can be quickly implemented and the costs are generally low. On the other hand, if you are setting up a full PKI system for authentication, single-sign-on, and to protect the integrity of documents, that will probably be considered long-term due to the increased costs in labor and equipment. Neither of these situations — or others — need to be viewed with a negative eye, however. You just have to figure out what management’s bottom line is.



Tangible versus intangible results
Sometimes the things that push management’s hot-button are not necessarily dollar figures; sometimes they are intangible results. If you can come up with a scheme that will make your boss look like a hero in his superior’s eye, you can often get what you want. Another intangible that often works well is to promote the positive effect your changes make in costumer confidence. Customer confidence is hard to put into dollars and cents, but the end result is loyalty — the customer is more likely to stay with you than to go to a competitor if the customer has confidence in your ability and your technical expertise.



Positive ROI (Return on Investment)
For those of you not familiar with the term ROI, it simply means Return on Investment. When you buy stock and the price goes up, you get a positive ROI because you’ve made money with your initial investment; a negative ROI is when the stock price goes lower than what you paid. Simple, isn’t it? For a number of years, the term ROI has been the buzz phrase with management. They often don’t even ask if the system will work — they just want to see a positive ROI (on paper in any case).

To be honest, there is no single, fool-proof method of determining a positive ROI. Although the concept of ROI is standard, the method of obtaining and tabulating the costs and figures is a bit like black magic. You can find hundreds of companies on the Internet who are more than willing to sell you special applications that are supposed to help you obtain ROI figures by messaging your numbers to fit your arguments. I don’t recommend buying these programs, and I can’t give you a definitive method of producing positive ROI figures for cryptography, but I can give you some helpful tips.
In order to argue that the use of cryptography in the workplace will give a positive ROI, you must collect data for the following:

• Cost of current security measures
• Effectiveness of current security mechanisms
• Cost of recent security breaches
• Current and future levels of threat
• Increased security
• New regulatory requirements for security
• Cost of cryptographic system(s)

When you have these facts and figures, you can start building a persuasive argument for the inclusion of cryptography into your systems. Remember that crypto is scary to a lot of people, so do your homework well.



Cost of current security measures
If your business is large and has IT departments scattered all over the country, it may be difficult to get an exact figure on the costs and effectiveness of current security measures. However, you can figure the cost of your own systems and use that as an average cost. If other offices are larger or smaller than your own, you can weight your figures accordingly and come up with a weighted average. Some of the figures you’ll want to include are replacement parts for electronics that will inevitably die at some point. You’ll also need to gather the salaries of the people responsible for network security. The reason that these costs are shown as a negative ROI is that they don’t generate any income in themselves and they are recurring yearly costs.
To obtain some positive ROI figures, keep in mind, also, the cost of the cryptographic solutions you will be proposing. In some cases, the business can take accelerated depreciation and can write off the total cost of the system the first year. Because the costs of the cryptographic solutions can be viewed as an upgrade and their costs may be written off, the net result for the business is that the costs are balanced by the write-off. In some cases, it may also reduce the costs of your company’s various insurance policies. That, certainly, is a positive result.



Effectiveness of current security mechanisms
This is somewhat of an intangible. If you haven’t had any security breaches with your current security mechanisms, you can’t really be sure if it was the security mechanisms that prevented breaches or if you have just been lucky not to have been targeted by hackers or other attacks. However, some real data can be computed by questioning the IT staff. Ask them how much time is spent reviewing firewall logs and responding to alarms sent by the firewall and intrusion detection systems. If the systems are sending out so many false-positive alarms that the IT staff no longer pays attention, then those security mechanisms aren’t really effective. They’ve become the equivalent of the Boy Who Cried Wolf. Calculate the number of man hours spent responding to alerts and use that as a negative ROI figure.

If your new cryptographic system increases the effectiveness of your network security, that is a positive ROI. For example, if all of your important data is encrypted, the theft of that data may not be as serious as if it had not been encrypted. Your effectiveness is increased because you can spend more time trying to find out who was responsible for the theft and less time on damage control on the data that has been stolen. The hours saved responding to security breaches are positive ROI.




Cost of recent security breaches
The Gartner Group specializes in gathering data on network security, security policies, and the costs of security breaches. In a recent report (2006), they found that a security breach costs medium- and large-size businesses $1 million for each security event. That figure is reached by calculating the amount of lost revenue (lost customers, drops in stock prices, labor costs to recover from the problem, and missed business opportunities). They also found that a significant number of businesses never recover from a serious breach. A serious breach is one that lasts three days or longer, and it must be noted that the average recovery time for most breaches is three days. Could your business survive three days with no network? Even viruses that don’t do any harm cost businesses a lot of money because cleaning up the servers of virus infections is quite labor-intensive.

Use the cost of security breaches as a negative ROI. On the other hand, if you can show that the installation and use of cryptographic systems can reduce or eliminate costs of certain types of security breaches, put that cost savings down as positive ROI.




Current and future levels of threat
With the threat figures, you can extrapolate how much money the company would lose if it suffered a serious hack that was made public. You’d lose the confidence (and probably the business) of some customers, and negative press could adversely affect the stock price or the value of the company. Additionally, you have to include the cost of labor to stop the hack, reverse any damage done, and plug all the holes that let the hackers enter in the first place. If trade secrets or future product data were stolen, that could well mean the end of the company.

The new regulations on financial companies and the health care industries require that you be able to prove you have done all you reasonably can to ensure the security of your corporate network. There are other situations in which you might have to prove your network is secure, like an audit by the FTC stemming from consumer complaints. Regardless of the reason, you want to have the best security possible to avoid lawsuits and governmental fines. If you see that your company could be included in any of those situations, you must pull together figures for legal advice, trial lawyers, PR firm consultations, and more. These can be very convincing numbers to management, and the likelihood of being found guilty of disregarding possible security mechanisms is a lot less if your system includes encryption.

Conversely, if you were to introduce some type of cryptographic solution into your network, you could avoid certain types of risk and show a positive ROI. For example, if all the personal data of your customers is encrypted, you save yourself the cost of lawsuits that can occur when personal data is either inadvertently released or when someone steals those files in order to sell the information. It’s pretty rare in the world of network security that you can say that a solution eliminates risk completely, but some crypto solutions can certainly help mitigate the risks.



Increased security
Many companies have spent tens of thousands — or even hundreds of thousands — of dollars on firewalls, intrusion detection systems, VPNs, and more. However, all of that protection works only on the data in transit. After the data lands on the servers, its only protection is access control. And we all know how easily access controls are subverted — old accounts, guest accounts, bad passwords, and sloppy administration allow unauthorized persons to access the data on the servers. This is the equivalent of connecting two wicker baskets with a steel pipe. The steel pipe protects the data in transit, but almost anyone can get access to the wicker baskets (the data at rest).

Intruders can and will get past firewalls, they can fool intrusion detection systems, and they can hijack network connections. In fact, if you read the stories and statistics, you’ll soon see that most hacks have focused on the data at rest and have not attempted to pick up the data while it was in transit. Credit card numbers, personal financial data, trade secrets, and software are usually stolen right off the server.

Imagine a scenario where the data in transit is adequately protected with a VPN or SSL connection. Likewise, the data at rest (on the servers) is protected by encrypting it. It would be hard enough for a hacker to get access to the VPN, and he would be doubly thwarted by finding that all the data he got looked like gobbledygook. This is an example of increased security at its best. It’s a bit like changing the wicker basket into a steel vault.

Increased security is always listed as a savings. Just look at the banking industry. By using encrypted SSL connections for online banking, the financial institutions have saved millions in the reduced number of staff needed to man phones for customer support. These companies have been able to let the customer take care of his business without having to interact with someone at customer service. Certainly customer service calls are still important, but Web transactions with SSL allow the customer service personnel to focus on more important tasks, and the customer can take care of the smaller chores such as transferring money between accounts and requesting more checks.

Consider what reduction in man hours can be had by incorporating encryption into your systems. If nothing else, you may be gaining disk space as some systems compress the data as they encrypt it. If the data is compressed to even 25 percent of its original size, that may save you having to buy new servers this year.



New regulatory requirements for security
California recently (2006) passed legislation that requires businesses to tell their customers when unencrypted data has been released — whether that release was accidental, intentional, or the result of a malicious act. If the business does not tell its customers of a security breach and is found out, huge fines could be the result. Notice that the law says unencrypted data. If your data is encrypted, you may have nothing to worry about!

Both the Gramm-Leach-Bliley Act and the Health Insurance Portability and Accountability Act (HIPAA) have certain requirements for companies to protect personal data. If the data is not protected adequately and personal information is released, the end result could not only be huge fines, but jail time for top management, too. However, if all of that data has been encrypted, it’s very likely that you can show due diligence in trying to protect your data. If you can show that you have done everything possible to protect your data, you may be able to save yourself from lawsuits and cumbersome fines.

If you think the California law and the two acts mentioned above are the only regulations you have to be concerned about, think again. The FTC has recently taken on the mantle of the protector of privacy rights, and they are not shy about prosecuting businesses. Even Microsoft has run a foul of the FTC and now has to comply with imposed security regulations and audits for the next 20 years. Think of the savings that would have been made if Microsoft had implemented their own encryption technologies — it would have saved them 20 years of submitting to audits and preparing reports. That would have been a huge positive ROI.




Cost of cryptographic system(s)
This is the main figure to start from, and it’s the one that management is probably going to complain loudest about. Some solutions can be fairly simple and not altogether expensive. For example, if you plan to implement e-mail encryption only, you may consider S/MIME, which has many freeware components. On the other hand, a full PKI system that handles secure e-mail, encrypted files, and standard document exchange protocols is a very pricey investment. However, you must consider any cryptographic system as an investment in ensuring your network security. If something reduces your risk of catastrophic events, then that isn’t such a bad thing.

In addition to the encryption software programs or suites that you plan to buy, you will probably need key servers and certificate servers, too. You may be able to utilize some existing hardware if it is currently in excess of your needs. Remember to add the cost of training and administration for the system, too.
To add a positive figure to the cost of the system, see if the increased security enables your business to enter new markets that were previously closed to you. For example, does encryption give you an edge over your competition that would allow you to take some of their business? Or does the use of encryption allow you to partner with or at least work with European companies that have a much higher standard for data security? Check out the Department of Commerce “Safe Harbor” program. You could get your network certified by the Department of Commerce so you could work with European companies.

Think of other benefits that are likely to come about through the company’s use of encryption. There may be lots of opportunities you may not have considered. Brainstorm with others in the company, and search the Web for ideas. Then present your case to management with all the positive aspects highlighted.



Government due diligence
There is new legislation that requires increased security, especially for personal data. If there is a complaint against your company, the government is duty-bound to investigate, and you better bet that they will. The government is very paranoid about network breaches allowing terrorists to gain entry to personal information and other sensitive data.

If the government decides to take a look at your network, they will do a complete security audit of your system. In addition, they will want to see documentation of all the security measures and mechanisms that you have considered, whether they were implemented or not. The government considers encryption a very good thing for network security. If your company can prove that you at least considered cryptographic systems to enhance your network security, you will be well on your way to showing that you exercised due diligence in considering every possible security solution. Many of the companies who have been recently dinged by the government with fines and 20-year oversight would never have had a problem if their data had been encrypted.



Insurers like it!
And last but not least is the fact that insurance companies are beginning to offer discounts for proof of increased network security. Insurance rates for businesses take a big bite out of the money bag, and the bean counters like to get every break they can. Like the government, insurance companies will insist on a full security audit, and the use of encryption adds a lot of positive check marks in the “good practices” column.



Presenting your case
Management is in love with PowerPoint presentations that are clear and well-designed. Get the best person on your team to put together the slides and don’t try to cram too much information into each slide. Try to stick to just the highlights and good points for your bulleted items. Remember, you are going to be the salesperson to get them to buy into an encryption scheme.

Prepare a spreadsheet with all the figures you’ve assembled. Here’s an example of what you might do:
Risks, Opportunities, and Solutions---------------------------------------------------Cost
Cryptosystem for encrypted e-mail and encrypted----------------–$50,000.00 data torage
Labor (yearly)------------------------------------------------------------------------–$75,000.00
Labor savings in reduced staff requirements (yearly)-----------+$100,000.00
Savings in reduced requirements for new storage----------+$90,000.00capacity (servers)
Labor costs for disaster recovery for this system------------–$5,000.00(yearly)
Labor costs for key recovery and help desk assistance------–$3,500.00(yearly)
Increased sales due to increased security---$600,000.00(average 15 clients annually)
Total cost of system----------------------------------------------------------+$656,500.00

Those types of figures should bring you a round of applause and possibly a promotion as well. In the table above, the negative amounts ( – ) are outgoing costs, and the positive figures ( + ) are savings or income for the company. In case you don’t have a calculator, the figure I used for increased sales was an average of $40,000 per customer. You can probably get those figures from your marketing department. Just ask them how much, on average, each customer is worth to the company.

In the following sections, I look at some of the situations that would benefit from the addition of cryptographic solutions to your current list of security mechanisms.



Do You Need Secure Communications?
There are many ways that we communicate with others on computers, and 95 percent of those communications are not secured against secret listeners. You won’t even be aware of the fact that your communications have been intercepted until or unless you suffer a security breach that can be related directly back to the messages.



Secure e-mail
If you aren’t aware of it by now, let me tell you in no uncertain terms that e-mail sent in the clear can be read by someone other than the intended recipient.

• E-mail goes astray.
  
• E-mail servers get hacked.
  
• E-mail traveling across the wires gets snagged like fish in a pond. If your e-mail isn’t encrypted, woe is you.

Imagine that you are working with an independent programmer who is building a new software program for you. Maybe that person sends you new code files every few days. Because your company is relying on this new program to make money for them, do you think it’s a wise idea to be sending these messages in the clear? What if your competition got hold of the code?

In another situation, imagine that you are an investigative journalist and you correspond daily with a number of sources who send you very sensitive material. Maybe it’s documentation of war crimes or human rights abuses. Maybe the head of a Fortune 500 company is engaging in illegal activities. Maybe you’re trying to track down the source of drugs coming into your community. All of these communications should be protected via encryption to ensure the confidentiality and safety of the informants. I could come up with a million situations, but you get the general idea.
Given all cryptosystems available, e-mail encryption is probably the easiest and cheapest system to implement. By “easiest” system, I don’t mean to imply that the setup is without problems, but it is an awful lot easier than setting up a full PKI system.

The two most common solutions for encrypted e-mail are

• S/MIME (Secure/Multipurpose Internet Mail Extension): MIME was created as a standard for transferring or transporting different types of files attached to e-mails, such as GIFs, JPEGs, DOC files, and so on. The S in S/MIME indicates a standard for incorporating secure encryption standards into the protocol. In a perfect world this would work perfectly; however, as is usually the case, the various vendors have taken to interpreting the standards to meet their own needs. S/MIME works, but different e-mail clients use it differently, and the results are not always fabulous. On the plus side, S/MIME is cheap and is included in most e-mail systems and e-mail clients (such as Outlook and Eudora).Because there are interoperability problems with S/MIME, it might be better to go with a vendor who has developed special implementations of S/MIME that have been altered to ensure better interoperability. Baltimore and ArcticSoft are two companies that come to mind with good products. These purpose-built systems tend to be pricey, but you get some good technical support in setting up and troubleshooting your system.
• PGP (Pretty Good Privacy)/GPG(GNU Privacy Guard or GnuPG):PGP has a very long and interesting history. To make a very long story short, it was created by a very non-techie person by the name of Phil Zimmermann at a time when the government was intent on keeping encryption technologies out of the hands of common people (1991). At that time, the only legal use of cryptography was by the military or government systems. The government filed charges against Zimmermann for violating export violations and six long years later, the government dropped the charges. Today PGP is a corporate entity, and its use has become a type of standard and is probably the most widely used e-mail encryption software in the world.
  PGP is available as freeware (GnuPGP) or as commercial software (PGP Corp). It’s an encryption and key-sharing protocol with a user interface to use with popular e-mail programs such as Outlook or Eudora. Its first interfaces were horrible and did a lot to scare people away from it, but the new versions are much nicer, and the program inserts buttons in the e-mail command bar of your e-mail program. However, for individual use it still takes some rooting around the manual to figure out all the intricacies of the product. The enterprise versions for company-wide installations are a good deal because of the ability they give the administrators to fix things such as lost keys. I give it a big thumbs-up because of its wide use and the relative ease of installation. It also interoperates well with older versions of PGP, so you don’t have to worry that your correspondence can’t be decrypted by the recipient. Another plus to PGP is that it has the ability to encrypt files and storage, where S/MIME does not have that capability.

Only a few years ago the world of IM belonged to teenagers. IM in its default installation not only introduces all kinds of security holes into your network, but almost anyone can read your messages, too. Whoops. There went your million dollars to the competitor and, by the way, hackers used IM to get into your network and are using it to distribute illegal MP3s. There have also been cases of people in the IT department snooping in on IMs to get information about impending layoffs.
To the rescue are secure IM servers and clients. The market is currently flooded with competitors like JabCast, Jabber, Bantu, and Ikimbo, to name just a few. They are reasonably priced (sometimes even free), and some systems come with a secure IM server as well as secure clients. Some of the programs use symmetric key encryption (the same key encrypts and decrypts) while other programs allow you to use public/private key pairs (you encrypt with your private key; the recipient decrypts with your public key). If you use your own IM server, all text is encrypted as it travels across the wires and as it sits on the servers. If you are using a public IM server, be sure you trust that server and find out what its security policies are.



Secure e-commerce
Any Web server that collects private information from customers should be considered an e-commerce server, and all possible protections should be implemented. Traditionally, only Web sites that conduct sales or financial transactions have been considered e-commerce servers, but I want you to think outside the box. Because of new privacy regulations, it may be in your best interest (and your customers!) to make your Web site more secure by using encryption.



California declares encryption a necessity
The California Encryption Act, as it is sometimes referred to, is very interesting because it is the first in the nation to be passed. It went into effect July 1, 2003, and businesses and security experts are waiting to see if it will stand up in court. Basically the Act says that if you have names and other personal information such as addresses or Social Security Numbers, you must protect that data. Encryption is an acceptable form of protection, but encryption of the data in transit is not enough. In short, SSL and S-HTTP are not good enough. You must encrypt the database and/or servers containing the information. In addition, if the information is stolen or released, you must notify people of the security breach. The Act is strongly worded, and it remains to be seen if other states adopt this stance.

Most secure Web servers use SSL (Secure Sockets Layer) and/or S-HTTP (Secure HyperText Transfer Protocol). Both of these options will encrypt the data as it travels across the wires to prevent the hijacking of information in the clear. On the other hand, these options do not encrypt the data that stays on the Web server or that is transferred to the database server. To be totally safe, you should encrypt the data on both the Web server and the database server.

Whether or not you use SSL and/or S-HTTP, you should know that the default installation of Web servers introduces train-sized security holes into your network. That’s because traffic to and from a Web server is supposed to be anonymous and, if the Web server is behind a firewall, you have to allow this traffic through the firewall. The default installations also frequently include scripts and default directories that can be used against you. So, if you plan on going into e-commerce in the future, be very, very careful and implement the best security possible. If you already have e-commerce up and running, then you need to double-check your security policies and procedures — and you really need to consider encrypting the data at rest, too.
Why the concern? Well, there are departments within the Federal government and agencies within state governments that impose severe penalties on companies that even inadvertently spill personal data. If you accidentally send out a customer list with personal information to all of your customers, you will be caught and charged. If a hacker gains entry to your Web server, database, or other network server and can gain access to personal unencrypted data, you will be found out and prosecuted. In fact, a new California state law states that if you have the personal information of even one California resident on a server, it must be encrypted — even if your servers are not located in California.



Online banking
Online banking is just another form of e-commerce. You’re collecting and disseminating personal information across the Internet. The Federal Gramm-Leach-Bliley Act of 1999 laid down regulations on safeguarding personal information collected, especially if the collecting is done online. And you don’t necessarily have to be a bank to fall under the shadow of this Act, either. If you handle information for banks, or if you counsel people on debt reduction, you will have to provide the following to the government:

• Risk assessment results
• Risk management decisions
• Results of testing for security weaknesses in your systems
• Attempted or actual security breaches or violations
• Responsive actions taken to breaches or violations
• Recommendations for improvements to the information security program (on a regular basis)
  

That’s a lot for some small companies or nonprofit organizations to bite off and chew. Again, encryption of your data in transit should be imperative, and you’ll have to show that you gave strong consideration for encrypting the data at rest. If you suffer a serious breach and you can’t show that you did all you possibly could (with the technology available at the time), then the FTC is going to take a big bite out of your bank account and certain company executives could end up wearing special jumpsuits for a long period of time.

Remember In addition to protecting the data coming, going, and resting, you should also be making sure that the user logon IDs and passwords/passphrases are encrypted. It won’t do you any good to install all kinds of fancy security mechanisms if people can get the UserIDs and passwords with little or no effort.



Virtual Private Networks (VPNs)
When businesses communicate over the Internet, there is no protection promised or implied. Everything is done out in the open and can be seen, captured, destroyed, or copied by anyone who cares to try. It’s like cities, towns, and villages connected by roads. You transport whatever is on those roads at your own risk. Businesses began to see the need for a safer alternative as they did business with remote partners and employees in remote locations. Thus, the Virtual Private Network (VPN) was invented.
VPNs use encryption to protect the traffic between any two points. It’s like building a tunnel with special access controls between those cities, towns, and villages. The tunnels aren’t available to everyone, and to the people up above, they are invisible. Before you can enter the tunnel, you must prove your identity, your packages must be of certain types, and the delivery address must be verifiable. If that isn’t secure enough for you, a VPN also has the ability to disguise the packages through encryption, too. That way, if someone manages to gain unauthorized access by fooling the access guards or by digging another tunnel that intersects with your tunnel, the intruder won’t know which packages to steal because he can’t tell one from another.

VPNs have been around for enough years now to consider them a standard security mechanism. On the other hand, the way vendors create their VPN hardware and software is not necessarily interoperable. If you are communicating with someone who doesn’t have the same sort of setup, it may take a few days or weeks of juggling cables and commands to get it working correctly. In general, VPNs are considered fairly reliable as far as security mechanisms go. Sure, there are hacks, but you really don’t hear about too many of them. Either they are not happening often, or companies are just not telling.

VPNs are capable of encrypting two different ways:

• transport: The transport encryption sets up a secure, encrypted link across the Internet wires, and it encrypts the data (payload) you are sending to the other end. This is the equivalent of the delivery truck carrying a package via the underground passageway. The encryption is invisible to the user — other than passwords, passphrases, or a special card to plug into the computer, the user doesn’t have to press a button that says “encrypt” or “decrypt.” All the data in transit is protected from sight. The only drawback to transport encryption is the fact that the headers on the data are sent in the clear. In effect, that’s like disguising the package and then putting a label on it that says what’s inside. Maybe not the smartest thing to do considering that intruders may occasionally gain access.
• tunneling: not only sets up a secure, encrypted link between two points, but it also encrypts the headers of the data packets. That’s better. Not only do you have a disguised package, but the address and the contents listed in the package’s label are in code so it’s not easily recognizable

As I mention earlier, the VPN standards aren’t necessarily standard, so you’ll have to see what protocols the vendor is using. The vendor will have tons of transfer protocols to choose from, but the tunneling protocols are fairly limited. Here are the tunneling protocols:

• GRE = Generic Routing Encapsulation
• IPsec = Secure Internet Protocol
• L2F = Layer 2 Forwarding
• PPTP = Point To Point Tunneling Protocol
• L2TP = Layer 2 Tunneling Protocol (PPTP + L2F)
  

If you set up a VPN for your customers, business partners, and employees, they can gain some comfort in the fact that their data isn’t traveling in the clear. One point to remember, though: Many road warriors have automated the process of logging in to their VPN and have a shortcut on the desktop. On top of that, a laptop is not properly protected with proper access controls — turn it on, and it’s yours. In that instance, a stolen laptop can easily be used to log on to a VPN, and you’d never know it unless the employee alerts you. In addition to access controls for laptops, you may also want to consider disk encryption to protect the data stored on the laptop. Just something to keep in mind.

VPNs are relatively easy to set up now, and you can usually find experienced staff to install and manage them. As I mention earlier, sometimes it takes a little effort to get two different VPNs talking to one another, but that doesn’t last forever. Many vendors are including VPN capabilities in their routers so the system is practically “plug and play.” Just remember to change the default settings such as the administrator password. VPNs are great at protecting the data in transport, but they do not encrypt the data on your drives — that data is still in the clear.



Wireless (In)security
Nothing has created such excitement as the introduction of “portable computers” in the ’80s. Now we not only have portable computers (our laptops, of course), but you can sit in a café, in a park, or in your back yard and connect to the Internet. No wires. No hassles. Just free and easy surfing the Web. Well, for every upside there has to be a downside, right? That’s certainly true for wireless networking. By default, anyone within radio wave distance can use your Internet connection and probably can hop on to your network as well. Shortly after wireless networking made its appearance, hackers created very small software programs that search the airwaves for unprotected wireless networks. And believe me when I tell you that there are tens of thousands of unprotected wireless business networks in America alone (2006).
The act of snooping for wireless networks is called war driving, so called because you can do it while you drive around town in your car (with a laptop inside). Teams of people have a war to see who can gain access to the most networks. (It also refers back to an old practice of “war dialing,” in which a hacker used a special modem that continually dialed telephone numbers in sequence in order to find modem tones to find networks.) Lists of open wireless networks can be found on the Internet, and in some cities the war drivers mark the sidewalks with chalk to indicate where the network is located and what you need to do to log on (war chalking). Wireless access points and wireless network cards are so easy to install that I doubt it would confuse a three-year-old. Even your grandmother can do it!

Wireless networks do have some security capabilities, and one of them currently in use is WEP (Wired Equivalent Privacy). Don’t stake your life on WEP, though, because it’s only an equivalent of security; it isn’t real security. WEP encrypts the packets going out over the air. It doesn’t encrypt them particularly well, though, and much of the information about the network is sent in the clear. There are many hacker programs available that can crack the basic configurations of WEP, too. AirSnort and WEPCrack are two popular programs. Of course I should also mention that WEP is much better than using nothing!

Given the number of business networks that appear on the war-driving Web sites, not many people have gotten the hint to at least turn on WEP, and even fewer know anything about securing WEP properly. Because WEP employs fairly weak encryption, you can add to the security by adding a VPN and an authentication process. This will greatly enhance your security, but you should never give a wireless network totally trusted status. In the near future there are supposed to be more secure versions of the wireless protocol appearing, but they haven’t quite made it yet. You can buy totally secure, NSA-approved wireless access points from Harris at about $5,000 each, but I doubt that many organizations will want to lay down that sort of money. The NSA has tested the encryption on the Harris wireless networks and found them to be safe. Well, probably not safe from the NSA, but you probably won’t have any problem with war drivers.