Symmetric encryption has two main characteristics: It is very fast (compared to asymmetric encryption) and uses the same key for encryption and decryption, as shown in Figure 24-2. As a consequence, the same key has to be known by the sender and the receiver. To ensure confidentiality, nobody else is allowed to know the key. Such keys are also called shared secrets.
Figure 24-2. Symmetric (Shared Secret) Encryption
Symmetric encryption has been used for decades, and several algorithms are commonly used. Among the best-known and most widely trusted symmetric encryption algorithms are Triple Data Encryption Standard (3DES), Advanced Encryption Standard (AES), International Data Encryption Algorithm (IDEA), the RC series (RC2, RC4, RC5, RC6), Software Encryption Algorithm (SEAL), and Blowfish. They are all based on the same concept: They have two types of input (the cleartext and the key) and produce unreadable output (the ciphertext). For decryption, the ciphertext and the key are the input data and the original cleartext is the output.
Symmetric algorithms are usually very simple in their structure, therefore quite fast, and as a consequence, they are often used for wire-speed real-time encryption in data networks. They are, in their essence, based on simple mathematical operations and can be easily hardware-accelerated using specialized encryption application-specific integrated circuits (ASICs). Typical applications are e-mail, IPsec, Secure Real-Time Transfer Protocol (SRTP), or Secure HTTP (HTTPS).
Keys should be changed frequently because they could be discovered otherwise, and loss of privacy would be the consequence. The "safe" lifetime of keys depends on the algorithm, the volume of data for which they are used, the key length, and the time period for which the keys are used. The key length is usually 128 to 256 bits. Because of the limited lifetime (usually hours to days) and the fact that each pair of devices should use a different key, key management is rather difficult.
Symmetric Encryption Example: AES
For a number of years, the industry recognized that Data Encryption Standard (DES) would eventually reach the end of its useful life. In 1997, the AES initiative was announced, and the public was invited to propose encryption schemes, one of which could be chosen as the encryption standard to replace DES.
On October 2, 2000, the U.S. National Institute of Standards and Technology (NIST) announced the selection of the Rijndael cipher as the AES algorithm. The Rijndael cipher, developed by Joan Daemen and Vincent Rijmen, has a variable block length and key length. The algorithm currently specifies how to use keys with lengths of 128, 192, or 256 bits to encrypt blocks with lengths of 128, 192, or 256 bits (all nine combinations of key length and block length are possible). Both block length and key length can be extended very easily to multiples of 32 bits, allowing the algorithm to scale with security requirements of the future. The U.S. Department of Commerce approved the adoption of AES as an official U.S. government standard, effective May 26, 2002.
AES was chosen to replace DES and 3DES because they are either too weak (DES, in terms of key length) or too slow (3DES) to run on modern, efficient hardware. AES is, therefore, more efficient on the same hardware (much faster, usually by a factor of around five compared to 3DES), and is more suitable for high-throughput, low-latency environments, especially if pure software encryption is used. However, AES is a relatively young algorithm, and, as the golden rule of cryptography states, a more mature algorithm is always more trusted. 3DES is, therefore, a more conservative and more trusted choice in terms of strength, because it has been analyzed for around 30 years. AES has also been thoroughly analyzed during the selection process, and is considered mature enough for most applications.
AES is the algorithm for encrypting both IP phone-to-Cisco CallManager communication (signaling with Transport Layer Security [TLS] protection) and phone-to-phone and phone-to-gateway (media with SRTP protection) channels in Cisco IP telephony.
Part I: Cisco CallManager Fundamentals
Introduction to Cisco Unified Communications and Cisco Unified CallManager
Cisco Unified CallManager Clustering and Deployment Options
Cisco Unified CallManager Installation and Upgrades
Part II: IPT Devices and Users
Cisco IP Phones and Other User Devices
Configuring Cisco Unified CallManager to Support IP Phones
Cisco IP Telephony Users
Cisco Bulk Administration Tool
Part III: IPT Network Integration and Route Plan
Cisco Catalyst Switches
Configuring Cisco Gateways and Trunks
Cisco Unified CallManager Route Plan Basics
Cisco Unified CallManager Advanced Route Plans
Configuring Hunt Groups and Call Coverage
Implementing Telephony Call Restrictions and Control
Implementing Multiple-Site Deployments
Part IV: VoIP Features
Media Resources
Configuring User Features, Part 1
Configuring User Features, Part 2
Configuring Cisco Unified CallManager Attendant Console
Configuring Cisco IP Manager Assistant
Part V: IPT Security
Securing the Windows Operating System
Securing Cisco Unified CallManager Administration
Preventing Toll Fraud
Hardening the IP Phone
Understanding Cryptographic Fundamentals
Understanding the Public Key Infrastructure
Understanding Cisco IP Telephony Authentication and Encryption Fundamentals
Configuring Cisco IP Telephony Authentication and Encryption
Part VI: IP Video
Introducing IP Video Telephony
Configuring Cisco VT Advantage
Part VII: IPT Management
Introducing Database Tools and Cisco Unified CallManager Serviceability
Monitoring Performance
Configuring Alarms and Traces
Configuring CAR
Using Additional Management and Monitoring Tools
Part VIII: Appendix
Appendix A. Answers to Review Questions
Index