Cryptography and the Web

Simson Garfinkel with Gene Spafford

Abstract

There are many cryptographic techniques, each addressing a different need. In some cases, the differences between encryption systems represent technical differences--after all, no one solution can answer every problem. Other times, the differences are the result of restrictions resulting from government controls, as we'll describe in this article.

Cryptography and Web Security

Confidentiality

Encryption is used to scramble information sent over the Internet and stored on servers so that eavesdroppers cannot access the data's content. Some people call this quality "privacy," but most professionals reserve that word to refer to the protection of personal information (whether confidential or not) from aggregation and improper use.

 

 
 
 

Digital signatures are used to identify the author of a message; people who receive the message can verify the identity of the person who signed them. They can be used in conjunction with passwords or as an alternative to them.

 

 
 
 

Methods are used to verify that a message has not been modified while in transit. Often, this is done with digitally signed message digest codes.

 

 
 
 

Cryptographic receipts are created so that an author of a message cannot falsely deny sending a message.

 

 
 
 

Before describing the cryptographic systems at work on the Web today, the following sections reveiw the basics of cryptography on which many secure Internet protocols are based.

Basics of Cryptography

For example, here is a message that you might want to encrypt:

SSL is a cryptographic protocol

Ç'^@%[ÈFÇ<<$TÞPÂ|xÀEÛóõÑ0/00ß+ö~ÖaÜýB-->uâw

Terminology

Encryption

A process by which a message (the plaintext ) is transformed into a second message (the ciphertext ) using a complex function (the encryption algorithm ) and a special encryption key .

 

 
 
 

The reverse process, in which the ciphertext is transformed back into the original plaintext using a second complex function and a decryption key . With some encryption systems, the encryption key and the decryption key are the same. With others, they are different.

 

 
 
 

The goal of cryptography is to make it impossible to take a ciphertext and reproduce the original plaintext without the corresponding key and to raise the cost of guessing the key beyond what is practical. Many modern cryptographic systems now easily achieve this goal. Indeed, cryptographic algorithms that have no known flaws are readily available today.

Figure 1

Cryptographic Algorithms and Functions

Symmetric key algorithms

With these algorithms, the same key is used to encrypt and decrypt the message. The DES algorithm discussed earlier is a symmetric key algorithm. Sometimes symmetric key algorithms are called secret key algorithms and sometimes they are called private key algorithms. Unfortunately, both of those names cause confusion with public key algorithms, which are unrelated to symmetric key algorithms.

 

 
 
 

With these algorithms, one key is used to encrypt the message and another key to decrypt it. The encryption key is normally called the public key because it can be made publicly available without compromising the secrecy of the message or the decryption key. The decryption key is normally called the private key or secret key .

Public key systems are sometimes (but rarely) called asymmetric key algorithms.

 

 
 
 

Public key algorithms overcome this problem. People wishing to communicate create a public key and a secret key. The public key is published. If Sascha wants to send Wendy a confidential message, all he has to do is get a copy of Wendy's public key (perhaps from her Web page), use that key to encrypt the message, and then send it along. Nobody but Wendy can decrypt the message, because only Wendy possesses the matching secret key.

Public key cryptography is also used for creating digital signatures [A] on data, such as electronic mail, to certify the data's origin and integrity. In the case of digital signatures, the secret key is used to create the digital signature, and the public key is used to verify it. For example, Wendy could write a letter to Sascha and sign it with her digital key. When Sascha receives the letter, he can verify it with Wendy's public key.

Public key algorithms have a significant problem of their own: they are incredibly slow. In practice, public key encryption and decryption runs betweeen 10 and 100 times slower than the equivalent symmetric key encryption algorithm. For that reason, there is a third kind of system:

Hybrid public/private cryptosystems

With these systems, slower public key cryptography is used to exchange a random session key , which is then used as the basis of a private (symmetric) key algorithm. (A session key is used only for a single encryption session and is then discarded.) Nearly all practical public key cryptography implementations are actually hybrid systems.

 

 
 
 

Message digest functions

A message digest function generates a unique (or nearly so) pattern of bits for a given input. The digest value is computed in such a way that finding an input that will exactly generate a given digest is computationally infeasible. Message digests are often regarded as fingerprints for files.

 

 
 
 

Symmetric Key Algorithms

Symmetric key algorithms can be divided into two categories: block and stream. Block algorithms encrypt data one block at a time, while stream algorithms encrypt byte by byte.

There are many symmetric key algorithms in use today. Some of the algorithms that are commonly encountered in the field of Web security are summarized in the following list:

DES

The Data Encryption Standard was adopted as a U.S. government standard in 1977 and as an ANSI standard in 1981. The DES is a block cipher that uses a 56-bit key and has several different operating modes depending on the purpose for which it is employed. The DES is a strong algorithm, but it is conjectured that a machine capable of breaking a DES-encrypted message in a few hours can be built for under $1 million. Such machines probably exist, although no government or corporation officially admits to having one.

 

 
 
 

DESX is a simple modification to the DES algorithm that is built around two "whitening" steps. These steps appear to improve the security of the algorithm dramatically, effectively rendering key search impossible. Further information about DESX can be found on the RSA Data Security "Cryptography FAQ," at http://www.rsa.com/rsalabs/newfaq/ .

 

 
 
 

Triple-DES is a way to make the DES at least twice as secure by using the DES encryption algorithm three times with three different keys. (Simply using the DES twice with two different keys does not improve its security to the extent that one might at first suspect because of a theoretical kind of known plaintext attack called "meet-in-the-middle," in which an attacker simultaneously attempts encrypting the plaintext with a single DES operation and decrypting the ciphertext with another single DES operation, until a match is made in the middle.) Triple-DES is currently being used by financial institutions as an alternative to DES.

 

 
 
 

The International Data Encryption Algorithm (IDEA) was developed in Zurich, Switzerland, by James L. Massey and Xuejia Lai and published in 1990. IDEA uses a 128-bit key and is believed to be quite strong. IDEA is used by the popular program PGP to encrypt files and electronic mail. Unfortunately, wider use of IDEA has been hampered by a series of software patents on the algorithm, which is currently held by Ascom-Tech AG in Solothurn, Switzerland.

 

 
 
 

This block cipher was originally developed by Ronald Rivest and kept as a trade secret by RSA Data Security. This algorithm was revealed by an anonymous Usenet posting in 1996 and appears to be reasonably strong (although there are some particular keys that are weak). RC2 is sold with an implementation that allows keys between 1 and 2048 bits. The RC2 key length is often limited to 40 bits in software that is sold for export. [B]

 

 
 
 

This stream cipher was originally developed by Ronald Rivest and kept as a trade secret by RSA Data Security. This algorithm was also revealed by an anonymous Usenet posting in 1994 and appears to be reasonably strong. RC4 is sold with an implementation that allows keys between 1 and 2048 bits. The RC4 key length is often limited to 40 bits in software that is sold for export.

 

 
 
 

This block cipher was developed by Ronald Rivest and published in 1994. RC5 allows a user-defined key length, data block size, and number of encryption rounds.

 

 
 
 

Public Key Algorithms

Since that time, a variety of public key encryption systems have been developed. Unfortunately, there have been significantly fewer developments in public key algorithms than in symmetric key algorithms. The reason has to do with the way that these algorithms are designed. Good symmetric key algorithms simply scramble their input depending on the input key; developing a new symmetric key algorithm simply requires coming up with new ways for performing that scrambling reliably. Public key algorithms tend to be based on number theory. Developing new public key algorithms requires identifying new mathematical problems with particular properties.

The following list summarizes the public key systems in common use today:

Diffie-Hellman key exchange

A system for exchanging cryptographic keys between active parties. Diffie-Hellman is not actually a method of encryption and decryption, but a method of developing and exchanging a shared private key over a public communications channel. In effect, the two parties agree to some common numerical values, and then each party creates a key. Mathematical transformations of the keys are exchanged. Each party can then calculate a third session key that cannot easily be derived by an attacker who knows both exchanged values.

 

 
 
 

RSA is a well-known public key cryptography system developed by (then) MIT professors Ronald Rivest, Adi Shamir, and Leonard Adleman. RSA can be used both for encrypting information and as the basis of a digital signature system. Digital signatures can be used to prove the authorship and authenticity of digital information. The key may be any length, depending on the particular implementation used.

 

 
 
 

Named after its creator Taher ElGamal, this is a public key encryption system that is based on the Diffie-Hellman key exchange protocol. ElGamal may be used for encryption and digital signatures in a manner similar to the RSA algorithm.

 

 
 
 

The Digital Signature Standard was developed by the National Security Agency (NSA) and adopted as a Federal Information Processing Standard (FIPS) by the National Institute for Standards and Technology (NIST). DSS is based on the Digital Signature Algorithm (DSA). Although DSA allows keys of any length, only keys between 512 and 1024 bits are permitted under the DSS FIPS. As specified, DSS can be used only for digital signatures, although it is possible to use DSA implementations for encryption as well.

 

 
 
 

Message Digest Functions

Figure 2

• Every bit of the message digest function is influenced by every bit of the function's input.
• If any given bit of the function's input is changed, every output bit has a 50 percent chance of changing.
• Given an input file and its corresponding message digest, it should be computationally infeasible to find another file with the same message digest value.

 

 
 
 

Many message digest functions have been proposed and are in use today. Here are just a few:

HMAC

The Hashed Message Authentication Code, a technique that uses a secret key and a message digest function to create a secret message authentication code. The HMAC method strengthens an existing message digest function to make it resistant to external attack, even if the message digest function itself is somehow compromised. (See RFC 2104 for details.)

 

 
 
 

Message Digest #2, developed by Ronald Rivest. This message digest is the most secure of Rivest's message digest functions, but takes the longest to compute. It produces a 128-bit digest.

 

 
 
 

Message Digest #4, also developed by Ronald Rivest. This message digest algorithm was developed as a fast alternative to MD2. Subsequently, MD4 has been shown to be insecure. That is, it is possible to find two files that produce the same MD4 codes without requiring a brute force search. MD4 produces a 128-bit digest.

 

 
 
 

Message Digest #5, also developed by Ronald Rivest. MD5 is a modification of MD4 that includes techniques designed to make it more secure. Although widely used, in the summer of 1996 a few flaws were discovered in MD5 that allowed some kinds of collisions to be calculated. As a result, MD5 is slowly falling out of favor. MD5 produces a 128-bit digest.

 

 
 
 

The Secure Hash Algorithm, developed by the NSA and designed for use with the National Institute for Standards and Technology's Digital Signature Standard (NIST's DSS). Shortly after the publication of the SHA, NIST announced that it was not suitable for use without a small change. SHA produces a 160-bit digest.

 

 
 
 

The revised Secure Hash Algorithm, also developed by the NSA and designed for use with the NSA's DSS. SHA-1 incorporates minor changes from SHA. It is not known if these changes make SHA-1 more secure than SHA, although some people believe that it does. SHA-1 produces a 160-bit digest.

 

 
 
 

Today's Working Encryption Systems

Working cryptographic systems can be divided into two categories. The first group are programs and protocols that are used for encryption of email messages. These programs take a plaintext message, encrypt it, and either store the ciphertext or transmit it to another user on the Internet. Such programs can also be used to encrypt files that are stored on computers to give these files added protection. Some popular systems that fall into this category include the following:

• PGP
• S/MIME

 

 
 
 

• SSL
• PCT
• S-HTTP
• SET and CyberCash
• DNSSEC
• IPsec and IPv6
• Kerberos
• SSH

 

 
 
 

Table 1: Comparison of Encryption Systems Available on the Internet Today

System	What is it?	Algorithms	Provides
PGP	Application program for encrypting electronic mail	IDEA, RSA, MD5	Confidentiality, authentication, integrity, nonrepudiation
S/MIME	Format for encrypting electronic mail	User-specified	Confidentiality, authentication, integrity, nonrepudiation
SSL	Protocol for encrypting TCP/IP transmissions	RSA, RCZ, RC4, MD5, and others	Confidentiality, authentication, integrity, nonrepudiation
PCT	Protocol for encrypting TCP/IP transmissions.	RSA, MD5, RCZ, RC4, and others	Confidentiality, authentication, integrity, nonrepudiation
S-HTTP	Protocol for encrypting HTTP requests and responses	RSA, DES, and others	Confidentiality, authentication, integrity, nonrepudiation; however, it's obsolete
SET and CyberCash	Protocols for sending secure payment instructions over the Internet	RSA, MD5, RC2	Confidentiality of credit card numbers, but nothing else; integrity of entire message; authentication of buyer and seller; nonrepudiation of transactions
DNSSEC	Secure Domain Name System	RSA, MD5	Authentication, integrity
IPsec and IPv6	Low-level protocol for encrypting IP packets	Diffie-Hellman and others	Confidentiality (optional), authentication, integrity
Kerberos	Network security service for securing higher-level applications	DES	Confidentiality, authentication
SSH	Encrypted remote terminal	RSA, Diffie-Helman, DES, Triple-DES, Blowfish, and others	Confidentiality, authentication

PGP

PGP is a hybrid encryption system, using RSA public key encryption for key management and the IDEA symmetric cipher for the bulk encryption of data.

Referring to the four basic encryption keywords mentioned at the beginning of this article, PGP offers confidentiality, through the use of the IDEA encryption algorithm; integrity, through the use of the MD5 cryptographic hash function; authentication, through the use of public key certificates; and nonrepudiation, through the use of cryptographically signed messages.

PGP is available in two ways, as a standalone application and as an integrated email program available from PGP, Inc. The standalone program runs on many more platforms than the integrated system but is more difficult to use. PGP, Inc., is also developing plug-ins for popular email systems to allow them to send and receive PGP-encrypted messages.

A problem with PGP is the management and certification of public keys. PGP keys never expire: instead, when the keys are compromised, it is up to the keyholder to distribute a special PGP key revocation certificate to everyone with whom he or she communicates. Correspondents who do not learn of a compromised key and use it weeks, months, or years later to send an encrypted message do so at their own risk. As a side effect, if you create and distribute a PGP public key, you must hold onto the secret key for all time because the key never expires.

PGP public keys are validated by a web of trust . Each PGP user can certify any key that he or she wishes, meaning that the user believes the key actually belongs to the person named in the key certificate. But PGP also allows users to say that they trust particular individuals to vouch for the authenticity of still more keys. PGP users sign each other's keys, vouching for the authenticity of the key's apparent holder.

Another way that PGP public keys are distributed is by the PGP public key servers located on the Internet.

S/MIME

S/MIME offers confidentiality, through the use of user-specified encryption algorithms; integrity, through the use of user-specified cryptographic hash function; authentication, through the use of X.509 v3 public key certificates (see the sidebar); and nonrepudiation, through the use of cryptographically signed messages. The system can be used with strong or weak encryption.

To send people encrypted mail with S/MIME, you must first have a copy of their public keys. It is expected that most S/MIME programs will use X.509 v3 public key infrastructures such as those being built by VeriSign and other certification authorities.

SSL

SSL connections are usually initiated with a Web browser through the use of a special URL prefix. For example, the prefix "https:" is used to indicate an SSL-encrypted HTTP connection, whereas "snews:" is used to indicate an SSL-encrypted NNTP connection.

SSL offers confidentiality through the use of user-specified encryption algorithms; integrity, through the use of user-specified cryptographic hash function; authentication, through the use of X.509 v3 public key certificates; and nonrepudiation, through the use of cryptographically signed messages.

The X.509 v3 Certificate The X.509 v3 certificate is a popular standard for public key certificates. X.509 v3 certificates are widely used by many modern cryptographic protocols, including SSL. (X.509 certificates are not used by the PGP email encryption program versions 2.0 through 4.5, but it is possible that future versions of PGP will support X.509 v3.) Each X.509 certificate contains a version number, serial number, identity information, algorithm-related information, and the signature of the issuing authority.  The industry has adopted X.509 v3 certificates, rather than the original X.509 certificates, because the X.509 v3 standard allows arbitrary name/value pairs to be included in the standard certificate. These pairs can be used for many purposes. Microsoft's Internet Explorer will display some of the fields if you choose the Properties option while looking at a secure document.

PCT

Although Microsoft is supporting SSL 3.0 and TLS, the new Transport Layer Security model, Microsoft intends to continue supporting PCT because it is being used by several large Microsoft customers on their corporate intranets.

S-HTTP

SET

There are three parts to the SET system: an "electronic wallet" that resides on the user's computer; a server that runs at the merchant's Web site; and the SET Payment Server that runs at the merchant's bank.

To use the SET system, you must first enter your credit card number into the electronic wallet software. Most implementations will store the credit card number in an encrypted file on your hard disk or in a smart card. The software also creates a public and a secret key for encrypting your financial information before it is sent over the Internet.

When you want to buy something, your credit card number is encrypted and sent to the merchant. The merchant's software digitally signs the payment message and forwards it to the processing bank, where the Payment Server decrypts all of the information and runs the credit card charge. Finally, a receipt gets sent back to both the merchant and you, the customer.

Banks that process credit cards are excited about SET because it keeps credit card numbers out of the hands of the merchants. That should cut down on a lot of fraud, because it is merchants (and their employees), and not teenage hackers, who are responsible for much of the credit card fraud in the world today.

SET offers confidentiality for credit card numbers, as they are encrypted using the RSA algorithm. But it does not offer confidentiality (and thus privacy) for the other elements of a user's transaction: this was a compromise necessary to gain approval to export the SET software without restriction. SET does provide for integrity, authentication, and nonrepudiation through the use of message digest functions and digital signatures.

CyberCash/CyberCoin

Before using CyberCash, the consumer must download special software from the CyberCash Web site, http://www.cybercash.com/ . The software, called the "CyberCash wallet," maintains a database of a user's credit cards and other payment instruments.

To use a credit card with the CyberCash system, the credit card must be enrolled. To create a CyberCoin account, a user must complete an online enrollment form. The current CyberCash implementation allows money to be transferred into a CyberCoin account from a credit card or from a checking account using the Automated Clearing House (ACH) electronic funds transfer system. Money that is transferred into the CyberCoin account from a checking account can be transferred back out again, but money that is transferred into the account from a credit card must be spent. CyberCash allows the user to close his or her CyberCoin account and receive a check for the remaining funds.

The CyberCash wallet registers itself as a helper application for Netscape Navigator and Micro-

soft's Internet Explorer. Purchases can then be initiated by downloading files of a particular MIME file type.

When a purchase is initiated, the CyberCash wallet displays the amount of the transaction and the name of the merchant. The user then decides which credit card to use and whether to approve or reject the transaction. The software can also be programmed to automatically approve small-value transactions.

If the user approves the transaction, an encrypted payment order is sent to the merchant. The merchant can decrypt some of the information in the payment order but not other information. The merchant adds its own payment information to the order, digitally signs it, and sends it to the CyberCash gateway for processing.

The CyberCash gateway receives the payment information and decrypts it. The gateway checks for duplicate requests and verifies the user's copy of the invoice against the merchant's to make sure neither has lied to the other. The gateway then sends the credit card payment information to the acquiring bank. The acquiring bank authorizes the transaction and sends the response back to CyberCash, which sends an encrypted response back to the merchant. Finally, the merchant transmits the CyberCash payment acknowledgment back to the consumer.

The CyberCash payment is designed to protect consumers, merchants, and banks against fraud. It does this by using cryptography to protect payment information while it is in transit.

All payment information is encrypted before it is sent over the Internet. But CyberCash further protects consumers from fraud on the part of the merchant: the merchant never has access to the consumer's credit card number.

DNSSEC

DNSSEC allows for secure updating of information stored in DNS servers, making it ideal for remote administration. Working implementations are available for free download from Trusted Information Systems ( http://www.tis.com/ ) and CyberCash ( http://www.cybercash.com/ ).

IPsec and IPv6

IPsec does not provide for integrity, authentication, or nonrepudiation, but leaves these features to other protocols. Currently, the main use of IPsec seems to be as a multivendor protocol for creating virtual private networks (VPNs) over the Internet. But IPsec has the capacity to provide authentication, integrity, and optionally, data confidentiality for all communication that takes place over the Internet, provided that vendors widely implement the protocol and that governments allow its use.

Kerberos

server and each individual user. Each user has his own password, and the Kerberos server uses this password to encrypt messages sent to that user so that they cannot be read by anyone else.

Support for Kerberos must be added to each program that is to be protected. Currently, "Kerberized" versions of Telnet, FTP, POP, and Sun RPC are in general use. A system that used Kerberos to provide confidentiality for HTTP was developed but never made it out of the lab.

Kerberos is a difficult system to configure and administer. To operate a Kerberos system, each site must have a Kerberos server that is physically secure. The Kerberos server maintains a copy of every user's password. In the event that the Kerberos server is compromised, every user's password must be changed.

SSH

Cryptography and U.S. Export Control Law

In 1992, the Software Publishers Association and the State Department reached an agreement that allows the export of programs containing RSA Data Security's RC2 and RC4 algorithms, but only when the key size is set to 40 bits or less. These key sizes are not secure. Under the 1992 agreement, the 40-bit size was supposed to be periodically reviewed and extended as technology improved. No review ever took place.

In early 1996, the Clinton Administration proposed a new system called "software key escrow." Under this new system, companies would be allowed to export software that used keys up to 64 bits in size, but only under the condition that a copy of the key used by every program had been filed with an appropriate "escrow agent" within the United States, so that if law enforcement so wanted, any files or transmission encrypted with the system could be easily decrypted.

In late 1996, the Clinton administration replaced the software key escrow with a new proposal entitled "key recovery." Reasoning that the main objection to the previous "key escrow" proposals was the fact that businesses did not wish to have their secret keys escrowed, the new proposal was based on a new idea. Under the key recovery system, every encrypted document or communication is prefaced by a special key recovery data block. The key recovery data block contains the session key used to encrypt the message, but the session key is itself encrypted with the public key of a federally registered key recovery service. In this way, the key recovery service can recover the session key by decrypting that key with the service's private key.

The key recovery proposal is different from the key escrow proposal in two important ways:

• Because the key recovery service does not hold any user's private key, that key cannot be leaked to compromise all of the user's messages.
• On the other hand, if the key recovery service's private key is leaked, then many, many users will have all of their messages compromised.

 

 
 
 

• What happens when a foreign government asks for the keys for a U.S. corporation that is in strong competition with a company that just happens to be based in the foreign country? (That is, what happens when France asks for Boeing's keys? What keeps the information learned from decrypting Boeing's communications from being transmitted to Airbus, Boeing's chief rival?)
• What happens when a rogue government asks for an escrowed key?
• What happens when foreign governments ask for the escrowed copies of signature keys. (What purpose could there be to requesting a signature key except to create fraudulent evidence?)

 

 
 
 

Foreign Restrictions on Cryptography

• It is widely believed that any direct restrictions on the use of encryption within the United States would be an unconstitutional violation of the First Amendment, which forbids Congress from making laws restricting the freedom of speech or the freedom of association.
• The United States has a history of both openness and governmental abuse of investigative power. Nevertheless, the current policy has allowed the federal government to claim that it has no interest in restricting cryptography used within the United States.
• Nevertheless, restricting the cryptography technology that can be placed in software for export effectively limits the cryptography technology that can be placed in software that is used domestically, because most companies are loath to have two different, and incompatible, versions of their software.
• Fortunately for the federal government, the argument of how restrictions on foreign software impact domestic software are so complicated that they go over the heads of most sound bite-oriented Americans.

 

 
 
 

There are many surveys that attempt to compare the laws with respect to cryptography in different countries. Unfortunately, many of the surveys currently have contradictory findings for many countries.

A rather comprehensive document comparing the various surveys on cryptography laws was completed by Bert-Jaap Koops in October 1996 and updated in March 1997. The survey can be found on the World Wide Web at the location http://cwis.kub.nl/~frw/people/koops/lawsurvey.htm . Between October 1996 and March 1997, many more countries had imposed export, import, and domestic restrictions on cryptography. This trend is likely to continue.

About the Authors

Simson Garfinkel is a computer consultant, science writer, and columnist for both The Boston Globe and HotWired , Wired Magazine 's online service. He is the author of PGP: Pretty Good Privacy (O'Reilly & Associates, 1994) and the coauthor of Practical UNIX & Internet Security (O'Reilly & Associates, 1996). Mr. Garfinkel writes frequently about science and technology, as well as their social impacts. The recently released Web Security and Commerce (O'Reilly & Associates, 1997) is his sixth book.

Euguene H. Spafford
Purdue University
Department of Computer Science
W. Lafayette, IN 47907-1398
spaf@cs.purdue.edu

Eugene H. Spafford is on the faculty of the Department of Computer Sciences at Purdue University. He is the founder and director of the Computer Operations, Audit, and Security Technology (COAST) Laboratory at Purdue. Professor Spafford is an active researcher in the areas of software testing and debugging, applied security, and professional computing issues. He is the coauthor of Practical UNIX & Internet Security (O'Reilly & Associates, 1996). He was the consulting editor for Computer Crime: A Crimefighters Handbook (O'Reilly & Associates, 1995), and has also coauthored a widely praised book on computer viruses.