Introduction

Interest in encryption arises from a history of technology transforming commerce. The need for secure communications has propagated the development of encryption schemes to protect the integrity of information as it is transferred electronically. There are a number of security services involved in encryption outside of the issue privacy: confidentiality--assurance that the parties involved in a communication have exclusive knowledge of the message; authentication--assurance that the parties involved are who they say they are; non-repudiation--proof of which party sent the message or which party received it; and time-date stamping--proof of when the message was created, sent and received. The encryption scheme itself can be classified as single-key or public-key based on its implementation.

Single-key encryption

The idea behind single key encryption is to encrypt a block of data using an encryption algorithm and a number called the "key," which is known only to the sender and the recipient. The key controls how the message is encrypted and every key does it differently. Thus, even it is known that a message has been encrypted using a specific algorithm such as DES, the Data Encryption Standard algorithm invented by IBM, it is impossible to decrypt the message without knowing the key as well.
An example of single-key encryption is a password on a word processing document or a PIN number on an ATM account. Single-key encryption is also called symmetric encryption, since the same key is used to encrypt a message from plaintext into ciphertext and to decrypt the ciphertext back into plaintext again. The key itself is a randomly-generated stream of bits of a specified length.
No matter how secure the encryption algorithm used to generate the key to encode the information, the single-key encryption system has two inherent security weaknesses. First, the sender and the recipient of the message need to share knowledge of the same secret key--meaning that each must trust the other not to compromise knowledge that is exclusive to them. This also makes anonymity almost impossible. Second, the communications channels used to exchange keys must be independently secured to prevent fraud.

Public-key encryption

Public-key encryption, also known as asymmetric encryption, solves both shared key risk and the distribution key problem. Instead of a single key, the public-key encryption system uses a pair of keys which are mathematically linked to each other--one of which is kept secret and the other which is transmitted. Each user possesses a private and public key pair which cannot practically be derived from each other.
With public-key encryption, only one key is needed to encrypt a message; the other is used for decrypting the message. A sender with a recipient's public-key can thus encrypt a message which only the recipient can decrypt using his private key. Likewise, a sender can encrypt a message with his private key which can be decrypted by anyone with the matching public key. In this way, a recipient with the sender's public key can verify that it was indeed the sender who originated the message. This is called a digital signature. Public-key encryption thus provides for both confidentiality and authentication.
The benefits of public-key encryption are clear. The sender and recipient no longer need to communicate previously, nor do they need to exchange private keys to send a communication that is signed and secure. They only need to exchange public keys, which can be done over open communication lines. Public-key encryption thus offers the possibility of a much more cost-efficient technology for securing communications.

Background

The idea behind public-key crytography was invented by Whitfield Diffie, a mathematician and computer scientist from MIT, in 1975. His big realization was understanding how to build a cryptographic system in which each communication was controlled by two keys instead of one. In addition, if the two keys were related, anything encrypted by one could then be decrypted by the other. However, Diffie did not solve the problem of designing mathematically-related keys that could not be derived from each other until he got together with Stanford Professor Martin Hellman. From 1975 to 1978, Diffie and Hellman co-authored a series of now-classic papers on public-key cryptography.
Several public-key encryption techniques now exist, subject to patents. Among them is the method pioneered by Massachusetts Institute of Technology professors Ronald L. Rivest, Adi Shamir and Leonard Adleman, known as RSA encryption. The mathematics behind RSA's asymmetric encryption is based on the notion of one-way functions. For instance, the product of two prime numbers, 31 and 97, is simple to calculate (=3007), but difficult to factor (=31 and 97). Likewise, raising numbers to powers is much simpler than taking roots; it takes a few seconds to find 2^12 (=4096), but longer to calculate the twelfth root of 4096 (=2).
RSA, which to date is the most successful public-key cryptographic system, combines the fact that raising numbers to powers is a one-way function relative to extracting roots and multiplying prime numbers is a one-way function relative to factoring. With the latter, if the product is large enough and no one but one person knows its factors, it constitutes a trapdoor that allows only that person to decrypt messages. For example, using cryptographic equipment, one can generate two large primes, each 300 digits long, whose product is 600 digits. This number is huge; the number of particles in the universe, for instance, is estimated to be less than 100 digits long. The 600-digit product is then made public, unfactorable by anyone except the originator. In fact, the largest number of this type that has been factored--129-digits--was initially proposed in the '70s and just solved last year.

Limitations

The theoretical limits of public-key encryption rest with the need to maintain the secrecy of the private key. Before transmitting the public key, a sender must first generate his own public-private key pair on a computer or other medium that can be kept secure from discovery. Thereafter, the sender only needs to publish his public key to enable others to send encrypted messages that only he can read.
Before using the key, however, any recipient needs assurance that the key is indeed the sender's public key and has not been erroneously generated, fraudulently generated or changed. To accomplish this, clients of public-key encryption support a class of trusted third parties, called certification authorities. These authorities certify the authenticity of a public key as a match to the private key held by the sender. They are the mechanism by which the identity of the parties involved in a communication is verified.
Certification authorities are divided into several levels, each certifying a public key with a fixed level of assurance, resulting in a precise degree of liability for error. At the highest level, the authority assumes all risks associated with verifying the identity of both parties while certifying the validity and enforceability of the transaction. Along these lines, a cryptosystem can only be trusted as much the certification provided by the authorities.
Certification authorities may charge a fee for their services to cover their costs and risks. The system actually requires trust rather than creating it, however. For instance, suppose the sender meets with an authority or else indirectly obtains all the information needed to issue a key-pair certificate. The certificate consists of sender's public key encrypted with the authority's own private key and thus, securely signed. The certificate is then stored on the sender's own computer system.
To prove his identity to a recipient, the sender encrypts a message with his private key as a digital signature and then appends his public key without encryption along with the certificate. The recipient can then use the authority's public key to verify that the appended public key is the same as the one encrypted by the authority's private key. Either public key can then be used to decrypt the original message.
Note that the requirement that the authority and the recipient must meet or have a trusted exchange obviates one of the principal advantages of public-key encryption--anonymity. In every encrypted transaction, the value places on anonymity must be balanced relative to the level of trust required. In addition, certification is only as trustworthy as the information given to the authorities. Errors or false generation of authority keys also create a trust problem. The solution to this is a hierarchical approach to key management, which an authority's key is certified by a higher level and attached.
Certification hierarchies tend to work well in structured organizations such as corporate networks. But for this scheme to be used in communications among different organizations, they must agree on a certification authority that can be trusted by all. This is not necessarily easy--for example, corporate users may not trust certificates signed by the certification authority of a competing company. The alternative to certification hierarchies is a web of trust where users decide for themselves which keys are valid. In other words, users will trust keys which come from a trusted source and arrive via a reasonably secure route--for instance, a worker may trust a key sent by another co-worker arriving via a secure private network vs. a key from purporting to be from an employee at another company arriving via the Internet. The certification hierarchy model can be thought of as a continuous client-server approach while the web of trust is a more distributed peer-to-peer approach.
The big advantage of the certification hierarchy model is that it is fairly easy to enforce a consistent policy within a large organization. On the downside, organizations that want to control who gets authenticated will need to set up and maintain their own certification authority, a process that requires specialized administration. The web of trust model, on the other hand, tends to offload many administrative headaches to end-users. Experienced users are likely to feel more in control since they are in control, but the key management process can also be quite a challenge.

Future Issues

There is an economic risk that transaction costs will rise as other types of assurance are required to provide new types of service such as secure key exchange, secure time-stamping and archiving, key escrow and secure networks for third-party certification as to a signer's level of corporate signing authority. In addition, the system makes the need for higher certification, with attendant security risks, greater in proportion to the degree of security required.
Encryption scheme vendors are constantly looking for areas of innovation for securing transaction systems. Such an area involves technological methods for ensuring trust. Another is the creation of security measures using cryptosystems in which security bears a relationship to the importance of the information being handled and the anonymity desired by the parties involved. Given the commercial interest in electronic commerce and the use of the Internet as a mechanism for disseminating information, these problems should attract a great deal of intellectual attention in the years to come.
Further systems are also needed to ensure that unwanted messages encrypted with the recipient's one public key are managed, perhaps replacing the exchange of encrypted messages with encrypted keys. If these fall into place, then a reliable system for secure message transmission and private communication can be made possible, and with a greater level of anonymity than is currently practiced on most on-line systems. From this, one may conclude that encryption techniques may beef up communal policies for managing communications and identifying abuses in the system.
Encryption development could affect decisions concerning the liability of on-line services or bulletin board systems (BBS) for disseminating unauthorized or unlawful material such as pirated software or pornographic material. For instance, a BBS that supports messages privately encrypted by its users creates a shield against liability for itself since the BBS operator can no longer exercise editorial control. Part of the problem in the past is the uncertainty of local jurisdiction and federal authority over on-line communications. The problem might be alleviated if all transmissions were encoded so that content were truly personalized. In addition to encoding a message in a form that enables its transmission, encryption also designates the assent of the viewer and ensures that only the holder of an authorized public key can read the information. In this way, private communication would be managed by private control rather than federal law.
Standardization and increased availability of encryption may also raise the standard for protecting proprietary information in the age of perfect digital reproduction. The heavy demands placed on copyright law to prevent unauthorized duplications may be eased dramatically if encryption is combined with on-line publication. The reason is simple: the decryption of a message encrypted with another person's key requires a computational act, which would be a significant factor in establishing criminal intent. Many states have already enacted computer crime laws to complement federal statutes that make unauthorized interception of electronic communications illegal. An unauthorized act of decryption is a sign of intent to seek illegal access to private communications and most likely will prove a point of great significance in criminal prosecution of interception and copying on-line in years to come.

Ethical Implications

As encryption becomes more widely available, lawyers have begun to provide guidance on the implications of its use, from the formation of contracts to criminal liability. Likewise, there has been recent litigation and government interest in legal standards for network security. Public-key encryption by itself has already spawned commercial and legal changes, including redefining terms such as "signature," "original" and "writing." 1
California itself has recently announced a "digital signature" statute to govern on-line transactions, defining legal requirements for a digital signature "intended by the party using it to have the same force and effect as the use of a manual signature." 2
The legal field must be involved in providing guidance on legal standards for encrypted electronic communications. Many secured transactions will shape security according to laws ranging from contract formation to criminal liability. The converse is also true, as the establishment of a standard fro commercial public key crytography will provide a foundation for addressing related legal standards.
Encryption is entirely legal for use inside U.S. borders. Yet encryption technologies, long used for protecting secret military and government communications, are legally regarded as munitions-- the same classification as a truck full of artillery shells--so are subject to strict export control. When PGP was anonymously posted to the Internet in 1993, for instance, inventor Phil Zimmermann became the target of a three-year criminal investigation that ended only early this year. Government security specialists fear that the widespread use of encryption could protect information involving criminal activities such as terrorism or drug trafficking. The government this restricts the export of all sophisticated cryptography in the interest of national security. Industry also has a vested interest in limiting encryption. Companies fear that disgruntled employees could encrypt corporate databases and throw away the key or hold them hostage.
Adoption of encryption appears to be proceeding more quickly for authentication than for privacy purposes, perhaps in part because products for authentication are not subject to the same export restrictions as those for privacy. However, the encryption industry is working hard to convince the federal government of its importance to U.S. export growth. Representatives argue that the government's policies are hampering the computing industry's global competitiveness. A report commissioned by the NSA and administered by the Bureau of Export Administration of the U.S. Department of Commerce determined that the U.S. market share for encrypted products in 1994 declined significantly in Britain, Denmark and Switzerland. In addition, sources in 14 countries told researches that U.S. export controls have limited the availability of sophisticated U.S.-made software for purchasing.
Currently, several industry coalitions are pressing for immediate action by the Clinton Administration to ease restrictions. One such group, composed of Apple Computing Corp., AT&T Corp., the Center for Democracy and Technology, the Electronic Frontier Foundation, Lotus Development Corp., MCI Communication Corp. and Tandem Computer, is asking the Administration for a policy that balances the issues of security enhancement, international interoperability, freedom for users to choose the method of encryption, marketplace acceptance, privacy protection and respect for the legitimate needs of law enforcement.
Meanwhile, the government is moving ahead with plans to enhance its existing Escrowed Encryption Standard (EES) to cover federal data communications. The government also touted the development of a private-sector alternative to EES, called the Clipper Chip, which would provide a standardized mechanism for encryption but also a backdoor that permits the government to eavesdrop on network and telecommunications.
Attracting consumers to the Internet is proving to be an uphill struggle, in part because of security concerns. Potential merchants of the Internet point out that 100 percent security cannot be guaranteed even in the real world. The issue is not so much about commerce than it is about privacy, however. Consumers have been especially wary of venturing into cyberspace for fear the personal information transferred and stored electronically will not be safe from hackers and cheats. In any case, paperless electronic commerce will not succeed until the security of on-line open systems is engineered to at least equal the level of security offered by traditional paper-based systems.

Introduction

hEwDY5eaKu5+VqUBAfwNZZCOfX66 ZXQVgKyvgGZ01Qd6D8DFq 7NIltXtb4Zf3DkPCzMJ+qsBXJotxkzdHn3dBJQYU0D+II651R kPmtApgAAAD05nOW7GK1t Auy6BGnGGwOZB2K2qVVCi - 4FEQOGRQxy TbyVGWQVT7nv5ae X88s513PW+or1rtQd5E N76jp8=Qh5W

That's "Hello. You look marvelous," spoken in PGP.

PGP or "Pretty Good Privacy," a program written by self-taught cryptography expert Phil Zimmermann, is the best-known and most popular encryption software available. In establishing PGP as an encryption standard for the masses, Zimmermann has earned folk-hero status among the growing cypherpunk subculture. PGP and Zimmermann's outspoken views on free speech have in many ways come to symbolize the debate over cryptography for the masses.
Phil Zimmermann, a product of 70s-era anti-nuke political action, has always held a fascination with cryptography. When he first heard about the public-key cryptography scheme developed by Diffie and Hellman, he toyed with the idea of implementing such a scheme for the personal computer platform. Zimmermann's philosophy about the public's right to cryptography is best related in his own words, from the product documentation he wrote for PGP:
"You may be planning a political campaign, discussing your taxes, or having an illicit affair. Or you may be doing something that you feel shouldn't be illegal, but is. Whatever it is, you don't want your private electronic mail or confidential documents read by anyone else. There's nothing wrong with asserting your privacy. Privacy is as apple-pie as the Constitution... If privacy is outlawed, only outlaws will have privacy. Intelligence agencies have access to good cryptographic technology. So do the big arms and drug traffickers... but ordinary people and grass-roots political organizations mostly have not had access to affordable military grade public-key encryption technology. Until now."

Background

Zimmermann began work on the project in 1984, having never had any formal training in cryptography. Instead of trying to come up with a completely new encryption algorithm, he decided to leverage off RSA, a public-key algorithm patented by RSA Data Security. The process was a slow one: Zimmermann completed his RSA implementation in 1986, but it was 1991 before his first version of Pretty Good Privacy was ready for release. It was a major accomplishment: effective, yet faster than any other encryption scheme on the market.
Although he had dedicated seven years of his life and had emptied his savings account in order to complete the project, Zimmermann made a surprising move: he decided to give the program away. He decided against charging a fee (as he had originally intended), because he was worried that the government would soon outlaw encryption altogether. By allowing PGP to propagate as widely as possible, Zimmermann hoped to ensure that the tools for privacy were well in place by then. PGP did indeed spread like wildfire: within hours of its release, it had been downloaded by people from all over the world.

Philosophy

Pretty Good Privacy's popularity has transformed Phil Zimmermann into a poster boy for the "cryptography for the masses" cause. Zimmermann's theology is passionate, interesting, and in the opinion of many, paranoid. In support of his ideas, Zimmermann draws an analogy to Americans' use of the US Postal Service. He poses the question, "What if everyone believed that law-abiding citizens should use postcards for their mail?" If this were the case, anyone sending their mail in an envelope would be subject to suspicion that they were hiding something. The reason using an envelope to send your mail through the postal system doesn't attract suspicion is the fact that most people use them, whether or not what they're sending is meant to be completely confidential. Envelopes, then, are an accepted means of asserting a right to privacy which, according to Zimmermann, is "as apple pie as the Constitution." Zimmermann suggests that many people use envelopes because they consider what they write to be nobody's business but their own, and they know that mail passes through many hands before arriving at its destination. Envelopes make it less feasible and more expensive for people to read your personal mail: about the only way to read sealed letters without leaving much evidence of the invasion is to painstakingly steam them open. Zimmermann argues that cryptography is simply the extension of this same privacy to the growing field of e-mail. In many ways, privacy is far less sure in e-mail than it is in a sealed letter: it is easy to intercept e-mail, undetected, at any of a number of points during its transmission. Once an e-mail transmission path is compromised, very efficient snooping is possible: while a conventional mail snooper might have to open hundreds of letters before finding one containing valuable information, an e-mail snooper can easily create a program to scan for and retrieve only those messages containing "key words" representative of messages that might interest them -- like "bomb," "illegal," "VISA" or "confidential." This makes e-mail monitoring feasible on a grand scale, in ways standard mail could never be. In fact, the NSA already routinely scans international cablegrams in this way!
Zimmermann has also been a vocal opponent of US Governement attempts to establish "key-escrow" data encryption standards like the so-called Clipper chip. In "key-escrow" systems, a trusted third party is effect given a copy of each chip's private key. This is done so that law-enforcement agents can be ensured access to encrypted information, provided they can procure if a warrant for the information. Zimmermann has a point when he says that the next logical step, critical to making key-escrow systems effective, would be to outlaw all other forms of cryptography. The implementation of a key-escrow scheme for all encrypted communication would make such communications only as secure as the third-party key holder is trustworthy... which was the very reason why Diffie developed the public-key concept in the first place. Electronic Frontier Foundation co-founder John Perry Barlow well-represented the seriousness with which cypherpunks protect their private keys when he said, "You can have my encryption algorithm... when you pry my cold dead fingers from my private key." Diffie did not intend private keys to be shared with anybody -- not collegues, not friends, not spouses, and certainly not unknown, self-interested key registry employees who would release keys at the first flash of a badge or warrant. Additionally, there is nothing to guarantee that a key obtained from a key registry will be used only for its intended pupose. A crooked law-enforcement agent could make a great deal of money by making digital copies of private keys from companies under investigation, carrying them out on a diskette, and selling the keys to competitors eager for market advantages.

Legal Issues

The legal issues surrounding PGP are numerous and complicated. The RSA public key cryptosystem, which Zimmermann used as the basis for the public-key technology in PGP, was developed at MIT, which holds a patent on it dating from 1983. The exclusive commercial license for the sale and sub-licensing of RSA is held by company named Public Key Partners (PKP). Thus, when PGP was originally released, PKP cried foul, charging that Zimmermann was blatantly violation U.S. law by using a patented, unlicensed algorithm in his product. Zimmermann countered that the program was a "research project," for which he was recieving no financial compensation, and was therefore not a violation of commercial copyright laws.
In order to dodge further legal hassles, PGP 2.0 was released by an international team of software engineers under Zimmermann's guidance. In a particularly witty move, the new version was released by Peter Gutmann in New Zealand, where RSA patents do not apply. Although it was released only in Europe and New Zealand, "it spontaneously spread to the USA without help from [Zimmermann] or the PGP development team," according to Zimmermann. Zimmermann and his associates obviously planned the release with this result in mind: although it is illegal to export powerful encryptioni technology, there is no law against importing it.
The freeware version of PGP is distributed by MIT, under the terms of the RSAREF license from RSA Data Security, Inc. (RSADSI). RSAREF is a subroutine package from RSADSI that implements the RSA algorithm. The RSAREF license allows for unlimited non-commercial distribution within the U.S. of programs using the package.

Technical Aspects

In order to speed encryption and decryption, PGP only uses the slower RSA technology for the public- and private-key components of the program. The main bulk of the encryption is done using IDEATM, which is conventional cipher covered by a European patent. Ascom-Tech AG, the patent-holder, has granted permission for royalty-free, interational use of IDEA in all non-commercial versions of PGP. Commercial and Government users must obtain the $99 licensed version released by ViaCrypt.
Although PGP is the reigning standard among encryption programs, its existing implementation is not very user friendly. Instead of operating in tandem with the mail readers users are most familiar with, PGP commands are executed by entering any of a number of command-line switches. Although there are a number of front-end interfaces available to simplify the encryption/decryption process, none of them hides the implementation to the point where a novice computer user could use it confidently. PGP, therefore, circulates primarily among more experienced computer users.

Principles

Although e-mail encryption protocols differ in particulars, any such protocol must provide two things: confidentiality and authentication. Confidentiality indicates that only the authorized recipient of a message can read it. Authentication is the guarantee that the message is really from its stated originator.
To provide these services, all primary protocols for encrypting e-mail rely on single-key encryption to encrypt the message, public-key encryption to encrypt the secret key, and a hash function to provide authentication.
With single-key encryption, both the sender and the recipient must know the key ahead of time--a logistical challenge if the two have never exchanged e-mail before. On the other hand, public-key encryption is not practical for use in encrypting entire messages since it is computationally expensive. Thus, typical e-mail protocols use single-key encryption to encrypt the e-mail message and then public-key encryption to encrypt the key used in encrypting the message.
Public-key encryption also works in conjunction with a hash function to provide authentication. Essentially, a hash code, also called a message digest, is a small chunk of data unique to a particular message but much shorter than the message itself. The hash code is like a digital fingerprint--each is so unique that it makes it possible to distinguish one message from another even if the two differ by only one bit.
To provide authentication, an encryption protocol extracts a hash function from the message, encrypts it with the sender's private key, and appends the encrypted hash code to the message. Although the hash code can be decrypted by anyone who knows the public key, a successful decryption verifies the identity of the originator.

Key Management

One of the key differences among the primary protocols is the size of the key used in encryption. Key size is an extremely important factor in ensuring cryptographic soundness. Since larger keys are computationally more difficult to break, larger keys imply stronger encryption. Many encrypting algorithms are considered cryptographically sound if and only if they are used with fairly large keys.
Key management is another important issue in protocol design. The way e-mail security schemes keep track of keys helps determine how much protection they ultimately provide. With a public-key system, key management must fulfill two parts: obtaining the public-key of a communications partner and verifying that the key belongs to that party.
Consider the so-called man-in-the-middle attack, in which an intruder inserts a relay process into the network between communications parties, pretending to be both of them. Thus, when one party sends a message to the other asking for his public key, the intruder intercepts the message and returns his own public key instead. If he does the same with the recipient, the intruder can intercept and decrypt encrypted messages from both sides and then re-encrypt or substitute his own message. Meanwhile, each side continues to believe it is communicating with the other.
Avoiding such attacks is one of the goals of key management. This is where the certification authority comes in. Physically, the certification authority can be many things, including dedicated hardware or software running on a server. In practice, however, for most secure e-mail applications, the certifications authority is likely to be software running on the mail server.
Regardless of the certification mechanism, the problem of bootstrapping trust remains. At some point, whether the mechanism is a hierarchy or a web of trust, the local e-mail client must be configured to specify which certification authorities and users should be trusted and which should not be.
In the certification authority, a single root authority is hard-wired into the client. The client software is then pre-configured to use a particular certification authority or a set of users which cannot be changed by the users. Thus, when a user first installs his e-mail package, the software already "knows" who to trust. Recently, however, it has become clear that a single root authority is not flexible enough. The answer is configurable certification authorities which allow users to choose certification authorities after verifying the authorities through some reliable channel.
The certification hierarchy most commonly used by secure e-mail schemes is the X.509 spec from the International Telecommunication Union-Telecommunications Standards Sector (ITU-TSS). The X.509 spec, which defines the relationship of the certification authorities, is part of a X.500 series of recommendations for a global directory structure using "distinguished names" to track users and other objects stored in a directory.

Protocol Types

Standards bodies and individual implementors have developed five primary protocols for e-mail encryption. Although the purpose of the schemes are the same--to protect e-mail as it travels over the Internet--they different encryption algorithms and authentication techniques. They also take different approaches to issues such as key management--issues which are just as important as encryption in ensuring the integrity of data. Finally, the design decisions vendors make to implement these protocols can determine how easy they are to use and administer, especially on a large network.

Secure Multipurpose Internet Mail Extensions (S/MIME)

Because it supports the encryption of multimedia data as well as plain text, S/MIME is considered one of the most fully featured secure e-mail protocols and is likely to become an Internet Engineering Task Force (IETF) standard. S/MIME guarantees interoperability between any two implementations while rival protocols only allow implementors to choose non-interoperable encryption options. Many Internet mail vendors plan to support the scheme, although commercial versions of S/MIME are not available yet. S/MIME is being developed by a group of companies led by RSA Data Security, Inc.
One potential drawback with S/MIME is that it permits the use of keys that are too small to ensure adequate security. All S/MIME implementations must include RC2, a proprietary crytographic algorithm from RSA with a 40-bit key. Because RC2 represents the lowest common denominator, any two S/MIME implementations can communicate with each other using RC2 as the default algorithm. The trade-off is security, however, since the 40-bit RC2 is not unbreakable. In fact, in a presentation at a Business Software Alliance conference last November, a panel of security experts maintained that 40-bit keys offer virtually no protection. They claimed that a hacker could easily crack a single 40-bit message in a weekend using borrowed computer time. According to the panel, a corporate engineering department with a $300,000 budget could build a machine that could crack five messages a second. Thus, any encryption scheme that operates with 40-bit keys should not be considered completely secure. However, S/MIME also supports two different versions of DES that use 56- and 168-bit keys.
Another cryptographic weakness of S/MIME, one that also affects MSP but not other schemes, is that eavesdroppers can distinguish between encrypted and signed-and-encrypted messages. More importantly, they can also tell who signed the message. If, for example, Marc Andreesen and Bill Gates were to exchange a number of signed messages, an eavesdropper might draw conclusions that Netscape and Microsoft were forging a business relationship.
S/MIME's key management scheme users the hierarchical structure defined in the latest update of X.509--Version 3, the most flexible up to date. This explicitly allows certification paths to start in the local security domain--the authorities controlled by an organization, for instance--of the public-key user system. The other notable feature of X.509 Version 3 is its ability to bind keys directly to e-mail addresses as opposed to only the X.500 distinguished names.
S/MIME's key management model is somewhat of a hybrid between certification hierarchy and the web of trust. Network manages must configure their own list of trusted keys--usually, the keys of trusted certification authorities. Full certificates are then included with every S/MIME signed message. Although this makes every message a few hundred bytes larger, this also makes key management a little easier. Whenever a user receives a signed message, the key of the signatory goes into the local key database where all keys are stored. If the key is signed by a trusted authority, trust is then established for that key and it can be used in the future without reverification.

PGP

Developed by Zimmermann in 1991, PGP has since become the de facto standard for mail encryption on the Internet. PGP is already commercially available via Viacrypt and other software companies. Version 3.0 will be released this year.
PGP's underlying cryptography is quite sound. For message encryption, it uses the International Data Encryption Algorithm (IDEA) with a 128-bit key. In fact, there is no mode of operation with a smaller key size, which makes PGP exceptionally safe.
Zimmermann designed PGP with the web of trust model for key management. This tend to be one of the scheme's biggest drawbacks, especially in business settings. Overall, PGP's key management is hard to learn, time-consuming, and dependent on a great deal of manual intervention. Every time a new key is needed either for checking a signature or encrypting e-mail, users must perform several manual operations. First, they must obtain the key, which maybe a remote operation. Next they must put the key into the local PGP key database, called a keyring in PGP terminology. Finally, they need to check if the key is valid. In PGP's current implementation, these steps require fairly complex command lines. However, key management may eventually become easier since this complexity is not inherent in PGP.

PGP/MIME

One of PGP's biggest drawbacks is in its inability to handle multimedia data. PGP/MIME attempts to solve the problem by adding the ability to handle MIME objects. The spec is currently wending its way through the IETF standards process. There are currently two implementations of the PGP/MIME draft: premail and the PGP/MIME reference implementation. Neither has been sold commercially.

MIME Object Security Services (MOSS)

Another attempt to encrypt multimedia data is MOSS, currently defined in Requests for Comment 1847 and 1848. Although no full-fledged commercial implementations have been available to date, there is broad support for adapting some parts of MOSS for use with other crytographic protocols, particularly the multipart/signed format which allows different parts of a message to be individually encrypted and signed.
MOSS is generally cryptographically sound, but since it does not mandate the choice of encryption algorithm nor key size, it could possibly operate with a small (not secure) key size. Also, choosing a different encryption algorithm can cause MOSS to fail to interoperate with other MOSS applications.
MOSS supports two modes of key management: X.509 and manual, using the web of trust. Users get more options, but a missing feature is the crytographic hash of the public key. Without it, users must either blindly trust the mechanism delivering the key or examine the entire key for signs of tampering, which can be cumbersome.

Message Security Protocol (MSP)

MSP attempts to revamp the secure e-mail protocols developed by NSA for its Defense Secure Data Networking Systems for use with Internet and MIME mail. The underlying protocol is standardized in the SDN.700 series of documents from the National Institutes of Standards and Technology while MIME integration is an IETF Internet draft. Although MSP has been around for a while, especially in X.400 environments, specifications and implementations for e-mail have emerged only recently.
MSP contains two features that no other protocol does. The first is a cryptographically strong signed-receipt capability, also known as a non-repudiation of receipt, which offers proof that the recipient actually received a message and that the message received is identical to the message sent. The second feature is the ability to classify messages--as "top secret," for example. An MSP client rejects messages if users do not have the appropriate authorization to read them.
One problem with MSP is that different implementations are not guaranteed to interoperate since two implementations may choose different and non-overlapping sets of algorithms. Before communication is possible, users must agree on both the MSP protocol and a specific algorithm set. The two main algorithm suites implemented for MSP are the Mosaic suite--same as the encryption used with the Clipper chip--and RSA with DES. A few implementations of MSP are already shipping, with several more in progress. MSP is a good choice for interactions with the government.
The key management of MSP, based on the X.509 certification hierarchy, closely resembles S/MIME's. Thus, it raises similar issues about signed message formats. At present it is still not clear whether MSP will be implementing the X.509 extensions that make handling of certification more flexible.

A major issue with all of these schemes is how they will be integrated with mail packages. In some cases, the encryption scheme is an additional application--for example, PGP is packaged in a single application that can work with existing mail packages, which is a large factor in its popularity. In general, however, these schemes are best integrated directly into the mail package. One reason for this approach is because integration makes it possible to integrate key management and the users' address books. If the encryption protocol is not integrated with the mail application, two address books are required: one to select e-mail address, the other to map e-mail addresses to keys. Because this requires users to keep track of two separate databases, this approach can be cumbersome.