For any arbitrarily sized message, the algorithm will generate a fixed size hash, which represents the message. It's evident from Table 1 that altering a message even slightly will change its hash. It'll be time consuming to find an alternate message that hashes to the same value.

So far we've discussed one-way functions that do not use a key. *message authentication codes* (MAC), on the other hand, are one-way functions that use a key. They can be used to authenticate files or messages between users, or on the system. *HMAC* (keyed hashing for message authentication) is an example in that category.

#### Symmetric ciphers

A *symmetric cipher,* when applied in conjunction with a secret key, translates *plaintext* to *ciphertext*. The cipher can also recover the plaintext from the ciphertext, using the *same* key. The symmetricity comes from using an identical key for both encryption and decryption. There are two related functions for encryption and decryption such that:

E_{k}(M) = C, whereMis theplaintext,Cis theciphertextandkis the key D_{k}(C) = M, whereC,Mandkhave the same meaning

They have the essential property that `D`

_{k}(E_{k}(M)) = M

Given a well designed algorithm, the security of the process lies in the secrecy of the keys. Consequently, the main challenge for symmetric ciphers rests in the distribution of keys -- how do the communicating parties share the same secret key? In contrast, asymmetric ciphers do not have to use the same secret key. Instead, they rely on a widely available and freely distributed public key.

Encryption using private keys is usually faster than with public keys. In a hybrid cryptosystem, the private key for the session, referred to as a *session key*, is established using public keys. The communicating parties use the session key for the rest of the session. That is one form of key exchange. Other forms of key exchange use more secure channels to exchange the private key.

Symmetric ciphers are classified as *stream ciphers* or *block ciphers*. Stream ciphers operate on the stream of bits or bytes, whereas block ciphers operate on a group of bits. The essential difference in the ciphertext is that the same plaintext block will encrypt to the same ciphertext block, using the same key for block ciphers, whereas it will encrypt to a different block every time it is encrypted when using stream ciphers.

Most block algorithms obey the *Feistel network* property, which means that the algorithms for encryption and decryption are the same, with some difference in the application of keys.

There are several *modes* of operation. Modes enhance encryption and can also alter the characteristics of a symmetric cipher. As an example, a block cipher can be made to behave like a stream cipher by the use of the appropriate mode. Listed below are a few important modes:

- Electronic CookBook Mode (ECB)
- Cipher Block Chaining (CBC)
- Cipher Feedback Mode (CFB)
- Output Feedback Mode (OFB)

There are several block ciphers, including the *data encryption standard* (DES). DES will be replaced by *advanced encryption standard* (AES).(See the sidebar, "AES: Crypto Algorithm for the Twenty-first Century.") Meanwhile, Triple DES (3DES or DESede), an improvement over DES, serves as a replacement until the AES is adopted. In DESede, the encryption procedure follows an encode, decode, and encode process using different keys in sequence, effectively increasing the key's length.

#### Asymmetric ciphers

Unlike symmetric ciphers that involve the use of the same key for encryption and decryption, asymmetric ciphers involve the use of different keys in such a way that:

E_{k1}(M) = C, wherek1is the encryption key D_{k2}(C) = M, wherek2is the decryption key

Asymmetric ciphers have the essential property such that:

D_{k1}(E_{k2}(M)) = M

In asymmetric ciphers, the communicating parties do not have to share the same key. However, the keys *k1* and *k2* are mathematically related for the encryption and decryption processes to work in conjunction.

#### Public and private keys

Asymmetric key ciphers are also referred to as *public key cryptography* since they involve the notion of a *public key*. A public key is freely available, whereas a private key is a secret. In a network of users, each user has his or her own public key published in a commonly accessible directory.

Whitfield Diffie and Martin Hellman and independently Ralph Merkle introduced public key cryptography in the mid-1970s. The security of public key algorithms is based on the difficulty of deducing *plaintext* from the *ciphertext* without knowledge of the key and the difficulty of deducing the private key from the public key.

It's important to understand that discussion of public and private keys in most literature can get confusing since many articles appear to use the same keys for encryption and decryption, but it's implicit in the discussion that one of them is the private key and the other the public key.

Another point to note is that when using multiple algorithms, multiple keys are required since the keys are unique to the algorithm.

Both digital signatures and certificates, discussed below, rely on public key cryptography.

#### Digital signatures

*Digital signatures,* much like real-life signatures, provide proof of authenticity of the sender and the integrity of the message. Digital signatures can be used for nonrepudiation -- the sender cannot deny that he or she signed it. Digital signatures need to be unforgeable and not reusable to be successful, and the signed document must be unalterable.

The basic digital signature protocol is:

- The sender encrypts the document with his/her private key, implicitly signing the document
- The message is sent
- The receiver decrypts the document with the sender's public key, thereby verifying the signature

Since signing large documents is time consuming, quite often only a hash of the message is signed. The one-way hash and the digital signature algorithm is agreed a priori. The original message is sent with the signature. The receiver verifies the signature by decrypting the hash with the sender's public key and matching it with the hash generated against the received message. Figure 1 below illustrates the signature generation and verification process. That scheme also has a nice effect of keeping the document and the signature separate.

Notice that the message uses a hashing algorithm to generate a fixed size hash, which is then encrypted to generate a signature. Those signatures are sometimes referred to as *digital fingerprints* since they represent the original message in a unique manner.

Using digital signatures does not guarantee confidentiality since the message is sent as plaintext. To further guarantee confidentiality, instead of sending the plaintext message, it could be encrypted with the receiver's public key, a process illustrated in Figure 2.

Digital signatures come in several algorithms, such as ElGamal signatures, RSA, or digital signature algorithm (DSA). Both ElGamal and RSA algorithms can be used for encryption and digital signatures. In contrast, DSA, part of the digital signature standard (DSS), can be used only for digital signatures and not for encryption. A separate algorithm for encryption has to be used in conjunction with DSA if encryption is desired.

Table 2 below concisely summarizes the characteristics of all the different cryptographic algorithms we have discussed so far and provides some examples in each category.

Cryptographic Algorithm | Brief description | Security Property | Issues | Examples | Security Property |

One-way hash functions | Produces a fixed-length unique signature | One-wayness of algorithm | Signature collisions | SHA, MD4, MD5 |

Message authentication codes (MAC) | One-way function, using a key | One-wayness of algorithm | Signature collisions | HMAC | Authentication |

Symmetric Ciphers | Encryption and decryption based on same key | Key length and algorithm | Key distribution | DES | Authentication, integrity, confidentiality |

Asymmetric ciphers(public key cryptography) | Different keys (public and private) for encryption and decryption. Public key easily available. | Key length, algorithm and difficulty of deducing private key from public key. | Trust issue | RSA, ElGamal | Authentication, integrity |

Digital signatures | Message hashed and encrypted with sender's private key for authentication | One-wayness and key length | No confidentiality | DSA, RSA | Authentication, integrity |

Digital signatures with encryption | Message signed and encrypted with receiver's public key | Signature, encryption algorithms, and key length | Trust issue | Combinations of digital signatures and ciphers | Authentication, integrity, and confidentiality |

#### Certificates

Since digital signatures depend on the integrity of the public keys, how can verifiers be sure that the public key they've obtained did not come from an imposter? Also, while digital signatures authenticate the sender, how can the receiver be sure of the sender's trustworthiness?

The answer to those questions lies in certificates. A mutually trusted third party or a certificate authority (CA) issues a certificate. The CA has more information about the user than merely the public key. Certificates contain, and an expiry date. The issuer signs the certificate with its private key. The implicit assumption in the process is that the CA's public key is widely available and genuine.

Public key certificates are based on the **X.509** standard. Some examples of CAs include Verisign, Thawte (now owned by VeriSign), and Entrust. In Java, the `javax.security.cert`

package provides certificate support.

#### Public key infrastructure

The relatively new public key infrastructure (PKI) has several meanings in different sources. One view states that PKI refers to trust hierarchy and public key certificates, while another view holds that it also encompasses encryption and digital signature services. PKI also addresses several key-related issues, including key registration, revocation, selection, recovery, and so on.

## Security standards

Table 3 lists a number of standards, some of which are complementary, and some are orthogonal to the algorithms and standards mentioned earlier. Those standards serve the useful purpose of being able to provide security, using commercially available products.

Protocol/Standard | Brief description | Relevant Algorithms |

IPSec (IP Security) | Cryptography-based security at the IP datagram layer | DES, 3DES, DH, MD5, RSA, SHA-1 |

OpenPGP (Open Pretty Good Privacy) | Security services for email and data files | DES, 3DES, DH, MD5, RSA, SHA-1 |

PPTP (Point-to-Point Tunneling Protocol | Used to create Virtual Private Networks | DES, RSA |

SET (Secure Electronic Transaction) | Secure credit card transactions | DES, HMAC-SHA1, RSA, SHA1 |

S/MIME | Security at application level | DES, 3DES, MD5, RSA, SHA1 |

Secsh (Secure Shell) | Secure remote access | DES, 3DES, RSA |

SSL (secure dockets layer) and TLS (transport layer security) | Secure pipe at the application layer | DES, DH, RSA, SHA1 |

## Other security considerations

Besides the concepts needed to understand the technologies behind security, good computer security requires that systems administrators:

- Know thy enemy
- Identify assumptions and weaknesses
- Control secrets
- Remember human factors
- Limit the scope of access
- Understand your environment
- Remember physical security
- Make security pervasive

Those factors are equally as important, if not more, as the technologies forming the foundation of security.

A closely related issue to security and cryptography is *privacy*, which deals with the rights and responsibilities that govern the acquisition, disclosure, and use of personal information. Privacy needs to be considered in the design of a software system in general and the security features in particular.

## Conclusion

In this article I have attempted to demystify the terminology behind computer security in general. Admittedly, there is a lot of terminology to deal with, but the fundamental concepts are simple. Beyond computer security, we've looked at cryptography's importance to security and examined its main features.

In the next article in this series, we'll relate those concepts to Java and its role as a programming language for the Internet. We'll discuss the aspects of Java security, its evolution, and its unique challenges to computer security. Finally, we'll touch upon issues that affect applet security; that is, the relationship of browser security to Java applets.