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
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
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
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
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 1038 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).