Encryption, in one form or another, has been around since
almost the dawn of civilization. Computers and networks have made advanced
forms of encryption possible. The kinds of encryption historically used (for
example, secret decoder rings or German Enigma machines) are trivial to break
on a computer, taking only seconds. Almost all versions of UNIX come with a
program called crypt, which is a software implementation of the German Enigma
machine used in World War II. A program exists on the Internet that breaks this
code in seconds. Therefore, when dealing with encryption, always insist on
using high-quality algorithms; weak ones can be broken easily.
Digital signatures are a way of securely signing documents.
This strategy is useful for two reasons. The first is like a regular
signature-to indicate that you agree with the terms of the document. The second
is to detect whether someone has changed the document after you signed it
(something that was unlikely with traditional paper documents). Digital
signatures are implemented by making a digest of the message, using an
algorithm such as MD5. This digest is encrypted by the user’s key. The
recipient can decrypt the encrypted digest and compare it to the document. If
the document doesn’t match, it has been tampered with or has a forged
signature.
Legal Issues
When writing Internet programs that involve encryption, it’s
very important to be aware of the legal issues involved. If you don’t, you
could end up in prison on felony charges.
First, some countries ban outright any use of encryption.
France and Iran are two notable examples. Therefore, you shouldn’t write any
encryption code, import any encryption programs, or even use encryption in
these two countries. Other countries might have such laws on the books. I
recommend checking with an attorney unless you are absolutely sure of the legal
status in your country.
The United States is another country with strange laws about
encryption. No problem exists with using any form of encryption you want-within
the country. The trouble starts when you want to write a piece of encryption
software in the United States and then export it to another country (except possibly
Canada) in electronic form. The U.S. government has labeled certain types of
encryption software as munitions-just as if these programs were missiles or
something. The law is known as ITAR (International Traffic in Arms
Regulations).
It’s possible to write certain types of weaker encryption
programs for export. You then have to request an exemption from the export law
from the U.S. government. The level of encryption allowed is strong enough to
be time-consuming for a cracker to break the code, but it can be done in a few
months on some machines. For public key algorithms, covered in the section
“Public Key Encryption,” the Software Publishers Association (SPA) and the
government agreed to give quicker approval to algorithms using 40-bit keys or
less. A message encrypted with a 40-bit key takes only about 200 MIPS/year of
CPU time (that is, a 200 MIPS computer would take one year to crack it).
Therefore, any highly secure, non-time-sensitive communication is potentially
at risk. Keep this fact in mind.
A few ways exist to get around this law. The best is to just
write your software outside the U.S. Some people ask the question, “What if my
machine is out of the country, but I’m in the U.S.?” or vice versa. My answer
is that there’s no legal precedent on this issue, so don’t take chances. The
other alternative is that apparently you can print out the source code (or
binary) to the program and carry the printouts out of the country without
violating the law. Then, in the foreign country, you can scan them back in.
Again, check with your lawyer before attempting this. Another method is for you
to write a U.S. version of the program that you tightly control, and then have
an associate write an international version outside the U.S. This has been done
with PGP (Pretty Good Privacy), which is discussed later in this chapter.
To make matters even worse, the law even precludes giving
the program to people in the U.S. who are not U.S. or Canadian citizens or
permanent residents. I know this part of the law is widely violated, but my
recommendation, as always, is to play it safe.
Another legal issue is that the major public key encryption
algorithms are all patented. The patent owners are pretty aggressive about
protecting their patents; however, many of the key patents expire in the next
couple of years. The release of these patents will break the stranglehold the
patent holders have had on public key encryption. I predict that after the
patents expire we’ll see many more public key encryption implementations than
we have today.
Private Key Encryption
Private key encryption is the oldest form of encryption in
existence. In private key encryption, there is one key. You encrypt the
message, using this key. The person decrypting the message must have the same
key. It works just like the secret decoder rings you might have played with
when you were a child.
The strength of private key encryption algorithms varies
greatly. Some are trivial to crack; others are computationally impossible to
crack, given today’s computers. Some vendors, notably WordPerfect, have
included some private key encryption code in their products. It turns out that
many of these are almost completely useless. You can download programs from the
Internet to crack the keys, run them, and have the original file back in under
15 minutes (the download is the time-consuming part, too!).
The most famous private key encryption algorithm is DES
(Data Encryption Standard). It’s very popular, and you can find implementations
for almost any platform available today. However, DES is aging (originally
published in 1975) and computers are getting faster. Attacks on DES are
becoming increasingly possible. A modified version of DES known as Triple-DES
is available and is harder to crack.
Public Key Encryption
The big problem with private key encryption is making sure
that the people on both ends of the communication have the keys-without anyone
else having them. The only ways to exchange keys in a secure fashion are to
already have a secure communication channel available, which means that both
parties already have encryption available; or both people must be in the same
place without anyone else around, so that they can be sure they’re not being
bugged. This is very cumbersome for most people.
Public key encryption eliminates the need for a secure
key-exchange mechanism. Each person has a private key, which he uses to decrypt
or digitally sign messages, and a public key, which others use to send messages
to him or to verify his digital signature. Each person keeps his private key
private to himself. The public key is public information and can be known by
anyone.
Key Length
The length of the key is a critical issue in the security of
a public key encryption algorithm. The longer the key, the safer your encrypted
messages but the longer it takes to encrypt or decrypt them. My advice is to go
ahead and use a long key (1024 bits or more). Most people today have enough CPU
horsepower to encrypt messages to you quickly, even with a long key. This isn’t
true when breaking messages without knowing the key, however. The longest
message known to be broken had a 429-bit key. It required an international
effort, involving 600 sites. The good news is that the amount of time needed
with current cracking algorithms doubles with every additional 10 bits of key
length. However, computer performance and algorithms to break public key
encryption algorithms are improving, making cracking easier. Therefore, a long
key is essential in protecting your messages for a long period of time.
Key Exchange
With public key encryption, the main implementation
difficulty changes from key exchange to identity verification. If someone
e-mails you her public key across the Internet, how do you know it’s really
from her? The answer is that you don’t. The secure way is to get together with
the person, in person, and exchange public keys. Well, if you do this, you almost
might as well have used private key encryption and exchanged keys. Also, this
model doesn’t scale well. Obviously, you can’t meet with every single person
with whom you need to exchange public keys.
Two basic models for key exchange have been developed. The
first is a hierarchical approach. At the top is a person or organization that
everyone has to trust. This person/organization hands out authority to other
organizations or people who can authenticate certain groups of people. These
second-tier authenticators then publicly publish the public keys of the people
they authenticate. This is the simplest form of this scheme. It’s possible (and
probably necessary) to have many more levels than this.
Organizations or individuals can issue a special document
known as a “Digital Certificate” saying that they have authenticated a certain
person. Then that person can show the digital certificate to others as proof of
her identity on the Internet. These digital certificates are usually in a
format known as X.509. One company issuing digital certificates is VeriSign
(http://www.verisign.com/). To use the Netscape FastTrack Server, you have to
acquire a digital certificate from VeriSign, though it should be possible to
use other companies in the near future (probably by the time you are reading
this).
The other model, known as the Web of Trust, doesn’t depend
on being able to trust these higher-level people and organizations. In the Web
of Trust, you initially exchange keys with at least a few people you meet in person.
Both of you can digitally sign each other’s keys with your names. Then, when
others later get your key over the network, they see that it’s signed by the
person with whom you exchanged keys in person. If they have exchanged keys in
person with that person and trust that person, they then know that they can
trust your key.
To make this system work well, you have to decide how much
you trust other people’s ability to validate and exchange keys correctly. If
you exchange keys with someone you don’t think validates people correctly, you
can later ignore any key you get over the network that is signed by that person
and not signed by someone you do trust. If you trust their validation
techniques, you take any keys signed by them. You can also partially trust them
with some implementations of this model. When you start thinking about scaling
this model, your head will probably start to spin, but it’s a powerful way for
small groups of people to communicate without a lot of overhead.
Most people tend to be rather religious about which model of
key exchange is the best. However, in reality, it has been proven
mathematically that either model can emulate the other model with a little
work. In fact, converting the Web of Trust into the hierarchical approach is almost
trivial. An organization only needs to create a key and then sign the keys of
people whom they can authenticate. If people know they can trust that
organization, they will accept keys that are signed by the organization as
being valid.
My personal belief is that both methods are flawed in some
ways. Therefore, this ability to twist one model into acting like the other is
essential. Sometimes you want to get keys from a central authenticated
database, especially when you can’t meet this person in person or can’t meet
someone who can meet them to handle the key exchange. At other times, you want
to get a key directly from someone (or slightly indirectly, from a source you
personally trust), so that you know it’s absolutely correct.
Popular Public Key Packages
The most popular piece of public key encryption software on
the Internet is PGP (Pretty Good Privacy). PGP is available for numerous
platforms and uses the Web of Trust model of key exchange. To get around the
legal restrictions, there’s a U.S. version of the program and a separate
international version that was written outside the U.S. Therefore, you can use
PGP without worrying about the export controls. (Just don’t carry a copy on
your laptop from inside the U.S. to other countries!) In reality, at least two
U.S. versions of PGP exist. A version for noncommercial use is freely available
by signing some documents with MIT. There’s also a commercial version known as
ViaCrypt PGP.
PEM (Privacy-Enhanced Mail) is another algorithm for public
key encryption. PEM is based on the hierarchical key exchange model. RIPEM
(Riodran’s Internet Privacy-Enhanced Mail) is the reference implementation,
which is available from RSA Data Systems. PEM seemed destined for greatness a
couple of years ago, but it really has taken a back seat to PGP in actual use.
MOSS (MIME Object Security Services) is intended to correct
a couple of the flaws of PEM, one being that PEM’s rigid hierarchies are too
strict on many occasions. MOSS relaxes the restrictions somewhat. MOSS is designed
to handle MIME messages, unlike PEM. MOSS has too many options, and it might be
possible for two different vendors to write MOSS implementations that can’t
speak to each other. Some people at the Internet Engineering Task Force (IETF)
told me and others to forget PEM, and that MOSS is the algorithm for the
future. However, upon researching for this chapter, I found material on the Web
indicating that MOSS is a niche system and that PEM was still alive and well. I
recommend watching market trends on this debate to see which side is better to
use and is gaining market share.
Buy Online Signing & Encryption Digital Signature Certificates Online At Digital Signature Mart.
Buy Online Signing & Encryption Digital Signature Certificates Online At Digital Signature Mart.
10:21 PM
Share:
