NOVA Online | Decoding Nazi Secrets | Are Web Transactions Safe?

Are Web Transactions Safe?
by Richard E. Smith

If you're reading these words with a Web browser, the program on your computer that enables you to view data from World Wide Web sites, you probably have better encryption at your fingertips than most of the soldiers and spies in World War II. Typical Web browsers today use encryption and other cryptographic techniques to protect you when visiting commercial Web sites. This makes credit-card transactions on the Internet even safer than they are over the telephone, since the techniques prevent eavesdropping and other forms of interference.

Cryptography, the art and science of secret codes, has evolved dramatically over the centuries, especially since World War II. For most of their history, codes have relied on sharing secrets between small groups of people who needed to communicate safely and privately. The shared secret might be a codebook that translated important words and phrases into short, nonsense words. This not only concealed a message's meaning but made it shorter. Codebooks were popular among wealthy individuals and large companies during the days of the telegraph. Since one had to pay for each word in a telegram, a well-designed code could reduce telegraph costs. Private companies produced codebooks that they sold to anyone who asked for them. The most effective codebooks were custom-made to be shared among a restricted group of business associates, who maintained their privacy by keeping their codes secret.

In the days of the telegraph, business executives often had real worries about the secrecy of their telegrams. Unlike a telephone call, which travels automatically without human intervention, each telegram had to be keyed in by a telegraph operator at the sending office, transcribed by an operator at the receiving office, and occasionally transcribed by other operators along its route. Telegraph operators were not always paid well enough to resist bribery, so sensitive business information could occasionally find its way into competitors' hands. Secret telegraph codes gave businessmen confidence that their private traffic remained private.

Secrecy doesn't always guarantee safety, however. Mary, Queen of Scots learned this lesson over 400 years ago, when agents of Queen Elizabeth I unmasked a plot against her by Mary's supporters. Mary used a codebook to communicate with her associates, but Elizabeth's spies succeeded in deducing the codebook's contents by reading numerous coded messages, guessing their contents, and systematically testing the guesses by trying to decode other messages. Although Elizabeth's agents didn't break Mary's entire code, they figured out enough of it to identify and arrest the plotters. While in prison, the plotters revealed the rest of the code, and Mary's decoded letters helped convict her of high treason.

Mary's code was not sophisticated enough to resist a systematic attack, but its present-day analogues generally are. Modern codes, particularly those used in computers, generally consist of two separate parts: the coding procedure, called the algorithm, and the key, which tells the algorithm how to scramble a message. The algorithm might be public knowledge, but the key is always kept secret. In essence, the secrecy of encrypted data relies entirely on the secrecy of the key. Instead of worrying about how to keep the data confidential, you need only concern yourself with keeping the key itself secret.

For example, today anyone can buy a pair of small electronic devices that encrypt data sent between two computers across telephone lines. However, Computer A can only understand data sent by Computer B if both of these special devices share the same key. The first device uses the key to encrypt the data using the shared, secret key, while the second device uses that same key to decrypt the information, making it readable to the recipient.

People rarely worry about eavesdropping on phone lines. Although we all know it can happen, it isn't usually a practical concern. Unfortunately, eavesdropping is rampant on the Internet. Organizations that track Internet security incidents constantly receive reports from Internet service providers of uninvited visitors. An eavesdropper will find a way to sneak into a provider's network and install a "password sniffer" program. As data pass through that part of the network, the sniffer collects user names and passwords, which the sniffer's owner will then use to log into other computers and masquerade as a legitimate user. There's a simple solution to this problem: encrypt passwords. Unfortunately, many systems still rely on secret passwords, which sniffers can easily capture.

Luckily, most companies that offer products or services through the Web do encrypt credit-card numbers transmitted over the Internet. If they didn't, criminals could use the same sniffing technique to collect those numbers for fraudulent purposes. Most commercial Web sites use special software called Secure Sockets Layer (SSL) to encrypt Web pages that might contain private information of yours. You can tell which pages are protected, because the page's Universal Resource Locator (or URL) begins with "https:" instead of the usual "http:" prefix. A careful site will encrypt a page in which you type a personal password or whenever you complete a merchandise order by providing your address and credit-card number. Sites use this information to decide if you really are the card's owner; only then do they charge a purchase to the number you've given them.

Now comes an interesting question: When your browser encrypts and decrypts data that it shares with a Web site, where does this secret key come from? If you've bought things over the Internet, you may have noticed the "https:" prefix and seen other indications that the browser was using its security features, though you wouldn't have noticed anything about sharing a secret key. If the Web browser's SSL software simply sent a secret key to the Web site, then eavesdroppers could intercept it and use it to decrypt your encrypted messages. So how does the browser solve this problem?

The answer is public-key cryptography, arguably the most important cryptographic innovation of the past 30 years. Public-key cryptography provides a safe and easy way for the SSL software to share a secret key between your browser and a Web site you visit. As with conventional encryption, the process uses public-key algorithms and separate keys to operate them. However, public-key algorithms work with two different keys, a public key and a private key. The public key can be distributed publicly, but the private key is always kept secret by its owner: an Internet site or a person. Anything encrypted with the public key can only be decrypted by the private key. This allows people to use a public key to encrypt a message that nobody can read except the owner of the corresponding private key.

SSL uses both public-key encryption and conventional secret-key encryption to achieve the best balance of speed, safety, and convenience. Say you're buying a book over the Internet from Amazon.com. First, the latter sends its public key to your browser. Next, your browser picks a secret key at random and uses Amazon.com's public key to encrypt it. SSL sends this encrypted secret key back to Amazon.com, which decrypts it. Once this exchange is complete, SSL uses the shared secret key to encrypt Web data sent between your browser and Amazon.com.

This strategy allows SSL to make the best use of public-key encryption without tripping over any of its mathematical limitations. Secret-key algorithms are much faster and can transmit lots of data more safely than public-key algorithms. Best of all, people using Web browsers don't have to bother themselves with encryption keys, either secret or public. The entire process sets up a safe and private connection automatically.

Just how safe is all this from a systematic attack along the lines of that made, albeit in simpler times, by Elizabeth I's agents? In other words, if someone wants to intercept Web-site passwords and credit-card numbers, how much effort would he or she have to go to? World War II codebreakers could break typical codes with pencil, paper, and lots of patience. SSL encryption used by a typical Netscape or Microsoft browser easily stands up against a pencil-and-paper attack, but computers dramatically speed up the process of tackling an encrypted message by trial and error. The deciding factor in attacking SSL encryption is generally the "size" of the secret key, measured in bits. Most Web browsers have a 40-bit key, which yields over a trillion possible encryption keys. A few years ago, researchers demonstrated that a lab filled with workstations could search all those keys and crack a single message in a matter of hours.

Encrypted credit-card numbers aren't valuable enough by themselves, however, to pay for the compute time spent to attack them. A few years ago someone attempted to sell a large collection of valid credit-card numbers to an undercover FBI agent, who bought them for the modest sum of $2.50 per number. That price hardly justifies the effort needed to decrypt them. Besides, in the United States, a credit card's owner is only liable for $50 in losses if the number is used fraudulently; the bank that issued the card or the merchant who accepted the purchase absorbs the rest of the loss. Thus, for most people, 40-bit keys are probably strong enough to protect their credit-card numbers.

Such keys aren't strong enough to protect everything, however. Fortunately, most browsers can use 128-bit keys, which offer 10³⁸ possible keys. Netscape and Microsoft offer these browsers as an option to U.S. and Canadian citizens, and other vendors offer similar software overseas. The secret-key algorithms work just as fast with 128-bit keys as they do with the shorter and easier-to-attack keys, and cracking a 128-bit key using today's computers would take at least a quintillion years.

Given that the 128-bit keys are as fast as and far safer than 40-bit keys, why do any browsers still use 40-bit keys? The answer is that Federal export laws mandate the weaker keys. Following World War II, U.S. officials declared all encryption devices weapons of war, and the State Department assumed authority to control their export. When Netscape developed SSL several years ago, the State Department granted the company permission to export only SSL software that used 40-bit secret keys, which are too short to use for military purposes.

A lively political debate has arisen around these export controls. The Clinton Administration and the FBI are trying to preserve the regulations—128-bit encryption would also interfere with wiretapping and electronic surveillance—while several legislators, supported by vendors of computer software and electronic commerce, would like to scrap the export restrictions. The controls, they claim, prevent U.S. vendors from building safer products and from competing successfully with overseas software companies, which have already developed and marketed numerous products with strong, 128-bit encryption. As in World War II, battles for the best codes rage on.

Dr. Richard E. Smith is an expert on cryptography and computer security at Secure Computing Corp. in St. Paul, Minnesota, where he consults on network security for commercial and government organizations. He holds a doctorate in computer science from the University of Minnesota and is author of Internet Cryptography (Reading, Mass.: Addison Wesley Longman, 1997).

Images: Icons courtesy Netscape and Amazon.com.

Crack the Ciphers | Send a Coded Message | A Simple Cipher
Are Web Transactions Safe? | Mind of a Codebreaker | How the Enigma Works
Resources | Teacher's Guide | Transcript | Site Map | Decoding Nazi Secrets Home