Encryption (open literature only)



Design Space



Encryption is used to protect the confidentiality of information when it must reside or be transmitted through otherwise unsafe environments. Encryption is also used for "digital signatures" to authenticate the origin of messages or data. Encryption algorithms themselves are rarely used alone in practice. Rather, they are typically embedded into a larger security systems to ensure their correct and consistent use, since a failure to do can compromise the security of other messages, even those that have been properly encrypted.

While there is greater general interest in cryptography and a larger commercial market than there was 15-20 years ago, the basic cryptographic algorithms are little changed over that period. For more information on the current technology and issues in cryptography, see Cryptography related sources on the Internet.

Design Space

Uses of Encryption

Encryption can be used in several different ways as summarized below. In addition to the characteristics of a particular encryption algorithm that are required to support a given use, the algorithm itself is generally integrated into a larger system that handles other aspects of the area to which encryption is being applied to ensure correct use and to minimize the visibility of the use of encryption. For example, if encryption is used for file protection, directories may also be protected and keys are managed on behalf of users so that normal file access does not change much.

Legal Issues and Civilian vs. Military Encryption

There is a bifurcation between civilian and military encryption. Military and intelligence algorithms are not publicly available, while civilian algorithms are mandated against for most military and intelligence applications. Further, while civilian encryption can be done in software, military encryption is generally (always) done in hardware to reduce the possibility of bypassing or corrupting the encryption process. This summary was written without access to information about defense-related encryption. As such, it addresses only encryption available for commercial use. It should definitely be updated if the application to be selected is a military one.

Export of encryption from the US is controlled by the International Tariff and Arms Regulations (ITAR). There are many legal impediments to the use or lack of use of encryption for various kinds of information, in various countries, with differing encryption algorithm strengths. These requirements overlap and seem to often conflict. This is an area of active public policy debate. Use of any particular encryption scheme needs to be considered carefully on an application by application basis, with particular concern for foreign use or sale. For an illustrative example of export policy, see NetScape Policy on Encryption Export.

Ideally it would be possible to encapsulate the encryption function so that any encryption process could be used. This however, is not so simple because of the differences in capabilities of public and private key encryption, key management, authentication issues, and the susceptibility of various algorithms to attack, all of which condition how a particular algorithm an be used. The NSA/DARPA ISSR/JTO programs are investigating modular security systems based on cryptography.

Encryption Strength

Encryption algorithms are generally rated by how much effort (time, processing power) is required to crack them based under a number of assumptions. These include amount of encrypted text available, whether the basic algorithm is known to the attacker, and whether encrypted text can be matched with its corresponding plaintext. In most cases, it is assumed that the attacker has access to all of these.

In general, attacks can be made more time consuming by increasing key length. Generically, it is easy to increase key length as the attackers power grows (due to faster computers); however, if the encryption is done in hardware this is not feasible. Even if this is possible, increasing key length requires that all users obtain new keys. The difficulties of key management are discussed below.

Because given enough time a key will be discovered, the long term viability of an encryption requires that the key be changed periodically. The stronger the encryption, the less frequently keys must be changed to prevent attack.

In general, because of increasing computing power, it is safest to assume that a message is not breakable only during a particular "time window" based on current and projected computing technology. Keeping messages secure for some time period is often sufficient because many messages are only important/embarrassing for a certain length of time. If perpetual security is required, there are theoretically unbreakable encryptions based on "one time keys" that are very secure but have enormous key management problems associated with them.

Key Management

To communicate, both sender and receiver need to share encryption/decryption keys (these may or may not be the same; see public vs. private). The dissemination of keys is of critical importance, since it is both cumbersome and a major source of vulnerability. There must be a way for a sender to let a receiver know the decryption key and to change that key as often as is dictated by the strength of the encryption (see Strength). Key use must be synchronized so that both sender and receiver are using the same key for a communication. Messages intended for groups require the same key for all group members. Keys are also usually changed periodically in case the key was inadvertently divulged. This channel must be secure (private and verifiable), so that the key is not divulged in transit and so that it is possible to know that the key was obtained from the correct source to prevent "spoofing" (pretending to be someone else in order to steal a message by getting them to encrypt the message to you rather than the real recipient). Couriers or complex protocols are used to exchange keys for private keys; public keys eliminate most key management problems.

Public vs. Private Key

The major differentiator between encryption methods is that of public vs. private key. In a traditional private key system, the encryption and decryption keys are identical and must be kept secret. Each pair of communicating partners or groups must have a secret key.

In a public key scheme, each individual has a pair of keys; a non-secret one for encrypting and a secret one for decrypting. The encryption key is known to anyone who wants it and is generally available from a well-known location to prevent spoofing. Because the encryption key is non-secret, anyone can encrypt a message for a particular recipient, but only the intended recipient has the decryption key allowing the message to be read.

Each user, i, has both a public key, Ei, which is made publicly available, and a private key, Di, which only user i knows. The keys are mathematically related, and both are generated by the user. Thus, there is no need for anyone else to hold the private key, which enhances security.

Public and private keys are inverses and are symmetrical, in the sense that for a given message m, Ei(Di(m)) = Di(Ei(m)) = m. To preserve privacy, a user X will obtain the public key Ey for user Y and compute Ey(m)). Since only Y knows Dy, only Y can decrypt. A checksum or some other identifying pattern is embedded into m so that a valid decryption can be verified.

Digital signatures work similarly, except that when X wants to sign a message to Y, X uses his/her private key Dx and computes Dx(m). Upon receipt, Y computes Ex(Dx(m)) = m. Since only X had knowledge of Dx, only X could have signed the message. Privacy encryption can be combined with digital signatures by computing Ey(Dx(m)), which is decrypted as Ex(Dy(Ey(Dx(m)))) = m.

The public key register of the Ei need not be read secure, since the Ei are given away freely. The registry must be protected against corruption, since that would allow fraudulent keys to be given out. The channel to the registry must be secure to prevent "spoofing" attacks, but this can be done using public key encryption.


There are two main algorithms used by various encryption products:


Listed below are a sampling of some important systems. Currently, DES, RSA, and PGP dominate the non-military cryptography scene; Clipper has potential future significance, and is an interesting study in the politics of cryptography.

The Catholic University of Louvain maintains a long list of cryptography vendors and research groups.

Data Encryption Standard (DES)

The current FIPS standard is 56 bit key DES. DES is widely used in commercial and non-defense government communications. Despite initial questions about the security of DES w.r.t. "trap doors", none have been uncovered in nearly 20 years. Current DES is nearing the end of its life as a encryption scheme for moderate to high level security needs because of technological advances that make brute force attacks on keys feasible. Designs exist for a hypothetical machine that for $1M could find one key in a matter of minutes by exhaustive search. Future processor speeds will lower the cost of exhaustive search to the point where it is feasible for anyone. For on-line information about the algorithm, see DES Update and Cryptographer's Homepage.


Escrowed Encryption Standard is a NIST Voluntary Standard for encryption of "voice, fax, and computer information over circuit-switched telephone systems." The goal of the initiative is to balance the needs of privacy with law enforcement and export with national security.

NSA provides the cryptographic algorithm (SKIPJACK) and the digital signature standard (DSS). The algorithms themselves are secret. Clipper is the name of the chip to actually do the encryption, and is the name by which the whole initiative is most commonly known. The algorithms will only be available in hardware; no software implementations allowed. Clipper provides a fairly high level of security (but not too high so that if exported it is breakable). Keys will be escrowed with either federal or commercial agencies; it is not clear yet which it will be. Escrowed keys would be available to law enforcement by court order. This has caused substantial controversy and is wildly unpopular on the WWW; ACM has urged its withdrawal. For more on key escrow, see CACM, 3/96.

The current standard is for telephony only and does not apply to email or directly to computer storage. The extension of the initiative to these areas is called CAPSTONE/TESTER/MOSAIC.

See: "Crypto Policy Perspectives", CACM, August, 1994; and Byte, 10/95, pg. 77.

RSA Data Security

Commercial encryption based on RSA. Besides the RSA homepage, see a short article Byte 10/95 p.77.


PGP (Pretty Good Privacy) is a publicly available encryption scheme based on the RSA algorithm. It has been widely distributed over the Internet. The legal, commercial version is available from ViaCrypt ($98). ITAR is a big issue with PGP, which has been the subject of considerable controversy. PGP claims to be both faster and more secure than RSA, but since it uses RSA, it is not clear how either claim could be true. One possibility is in the key management used by PGP. PGP can be integrated with email via scripts (FAQ 2.7). For more detail and claims, see the PGP FAQ page.

This research is sponsored by the Defense Advanced Research Projects Agency and managed by the U.S. Army Research Laboratory under contract DAAL01-95-C-0112. The views and conclusions contained in this document are those of the authors and should not be interpreted as necessarily representing the official policies, either expressed or implied of the Defense Advanced Research Projects Agency, U.S. Army Research Laboratory, or the United States Government.

© Copyright 1996 Object Services and Consulting, Inc. Permission is granted to copy this document provided this copyright statement is retained in all copies. Disclaimer: OBJS does not warrant the accuracy or completeness of the information on this page.

This page was written by David Wells. Send questions and comments about it to wells@objs.com.

Last updated: 7/2/97 sjf

Back to Internet Tool Survey -- Back to OBJS