Understanding Security Algorithms

It is almost hard to imagine modern computing and networking without also thinking about the mechanisms that provide for the underlying security of the data that resides on these systems or travels across the wire. Security algorithms are central to securing the data created within an organization, as well as securing it in transit. This section examines the characteristics of the encryption process and what makes for a strong, trustworthy encryption algorithm. This section also explores the use of cryptographic hashes and how key management plays an important role in securing the encryption process.

Selecting an Encryption Algorithm

Proper selection of an encryption algorithm is one of the key steps in building a cryptography-based solution. With this selection process, two main criteria should be considered. Table 12-8 details these selection criteria for your consideration.

Table 12-8 Criteria for Selecting an Encryption Algorithm

Selection Criteria


Trust in the algorithm by the cryptographic community

Because many new algorithms are often broken very quickly, algorithms that have stood the test of time by resisting attacks for a number of years are the most preferred. Although there is often a great deal of talk about the benefits of a new algorithm, there are truly few or no revolutions in cryptography.

Protection against brute-force attacks

A trusted algorithm has no shortcut to break it. An attacker has to search through the keyspace to guess the correct key. An algorithm also must allow key lengths that satisfy an organization's confidentiality requirements. This is not always the case. For example, DES does not provide enough protection for most organizations because of its short key length.

The following symmetric encryption algorithms are considered trustworthy:

Each of these algorithms has its place. For instance, because it uses very short key lengths, DES is a good protocol to protect data for a very short period of time. If you need to protect data with an algorithm that is very trusted and has much greater security strength, 3DES would be a much better choice.

AES, although not proven to the degree that 3DES has been, is still a good choice, because it is more efficient. This makes it ideal in high-throughput, low-latency environments. This is particularly the case when 3DES cannot handle the throughput or latency requirements. Over time, AES will likely gain even greater trust as more attacks are attempted against it.

Symmetric encryption algorithms such as RSA and Diffie-Hellman (DH) are considered trustworthy for confidentiality. But many others, like ECC, generally are considered immature in cryptographic terms.

Understanding Cryptographic Hashes

Hashing is used to provide data integrity. Hashes are based on one-way mathematical functions. These can be easy to compute but extremely challenging to reverse. The process of hashing and the difficulty of reversing the hash is akin to scrambling an egg and then trying to put it back together again.

Working with Hashing

The way that hashing works in practice is that data of arbitrary length is input into the hash function and then is processed through the function, resulting in a fixed-length hash. The resultant fixed-length hash is called a digest or fingerprint. Figure 12-7 shows the hashing process.

Figure 12-7 Hashing Process

Data of Arbitrary Length

Data of Arbitrary Length


Fixed Length Hash

If you are familiar with the calculation of cyclic redundancy check (CRC) checksums, hashes are quite similar to this but are cryptographically much stronger. If you're not too familiar with CRC, if you have the CRC value, it is relatively easy to generate data with the same CRC. Because of the strength of hash functions, it is computationally infeasible for an attacker to possess two separate sets of data that would come up with the same fingerprint.

Designing Key Management

One of the most challenging aspects of designing a cryptosystem is planning for key management. In fact, cryptosystem failures have occurred because of shortcomings in key management. Each of the current cryptographic algorithms requires the services of key management procedures, making this an extremely important area to consider. For an attacker, the general target when seeking to attack a cryptographic system is the key management system, rather than the algorithm itself.

Components of Key Management

When considering key management, you must consider several components that address the life cycle of key management from generation to destruction:


■ Key verification

■ Key revocation and destruction

Modern cryptographic systems generate keys automatically, rather than leaving it to the end user. To help ensure that all keys are likely to be equally generated, so that the attacker cannot predict which keys are likely to be used, quality random-number generators are necessary. It is not uncommon for a cryptographic algorithm to have some weak keys that should not be used. Proper key verification procedures should be used to regenerate these keys when they occur.

Key storage is another factor that must be considered. With today's modern multiuser operating systems that work with cryptography, a key can be stored in memory. When memory is swapped to the disk, it presents a possible problem, because a Trojan horse program, if installed on the PC, could then gain access to that user's private keys.

A secure key exchange mechanism is also necessary. It should allow secure agreement on the keying material with the other party, likely over an untrusted medium.

The final element of good key management to consider is key revocation and destruction. The process of key revocation notifies all the parties involved that a given key has been compromised and should not be used. Key destruction goes beyond this by erasing old keys so that a malicious attacker cannot recover them.

Understanding Keyspaces

The keyspace of an algorithm represents a defined set of all possible key values. For each key of n bits, a keyspace is produced that has 2n possible key values. This means that adding 1 bit to the key would effectively double the size of the keyspace.

Let's look at DES by way of an example. DES employs a 56-bit key and with this produces a keyspace of more than 72,000,000,000,000,000 (256) potential keys. If we were to add 1 bit to the key length, the keyspace would double. That means that an attacker would need twice as much time to search the keyspace.

No algorithm is without some weak keys in its keyspace, as discussed previously. These weak keys may enable an attacker to break the encryption via a shortcut. So what exactly constitutes a weak key?

A key is said to be weak when it shows regularities in encryption or poor encryption. A good example is DES. DES has four keys for which encryption is exactly the same as decryption. Should one of these weak keys be encrypted twice, the original plain text would be recovered.

The chance that such keys would be chosen is almost unimaginable. However, each implementation should still verify all keys and take steps to prevent weak keys from being used. This is particularly the case with manual key generation, so you should take special care to avoid defining weak keys.

Issues Related to Key Length

As we have discussed, the only way to break a proven cryptographic system is with a brute-force attack. These attacks search the entire keyspace, trying all possible keys, until the key that decrypts the data is found. To defend against this form of attack, the keyspace must be sufficiently large enough that such a search would require an enormous amount of time, rendering this form of attack impractical.

Even for successful brute-force attacks, generally an attacker has to search half the keyspace to find the correct key. Of course, the time required for such a search depends on the computer resources available to the attacker. With key lengths of significant size, such an attack could take many millions, if not billions, of years to yield success.

The protection strength of modern trusted algorithms depends exclusively on the length of the key. You should select a key length so that it protects data confidentiality or integrity for an adequate period of time. The more sensitive the data, and the longer the period required for secrecy, the longer the key that must be used.

When considering the level of protection required, you must also take into account the characteristics of those likely to attack your data. For instance, you must estimate the attacker's resources and how long you must protect the data.

For example, suppose a would-be attacker has $1 million of funding that can be used toward the attack, and the data must be protected for a period of no less than one year. What form of encryption should we choose? Classic DES would not be a good choice, because it can be broken by a $1 million machine in only a couple of minutes. If instead we employed 168bit 3DES or even 128-bit RC4, it would take that same attacker, funded with that same $1 million, a million years or more to crack into your data. Considering our attacker, his funding and our need for security are both important in selecting the proper key length.

Another issue impacting the choice of key length is performance. It is important to strive to balance speed and protection strength for the selected algorithm. Certain algorithms, such as RSA, take much longer to run with large key sizes. We should strive for adequate protection, without hindering communication over untrusted networks.

Finally, you also need to be aware that because of rapid advances in technology and cryptanalytic methods, what may be an adequate key size today may quickly no longer be appropriate. The National Institute of Standards and Technology (NIST) offers recommendations on adequate key lengths for various applications. You may review these on the NIST website at http://www.keylength.com/en/47.


Security on the Internet for such applications as web browsing, e-mail, Internet faxing, instant messaging, and other forms of data transfer is provided by cryptographic protocols. Among the most popular choices to support these applications are Transport Layer Security (TLS) and its predecessor, Secure Socket Layer (SSL). Although there are subtle differences between SSL and TLS, the actual protocol remains quite similar.

Both SSL and TLS support a variety of cryptographic algorithms, or ciphers, to help provide such functions as authenticating the server and client to each other, transmitting certificates, and establishing session keys. For bulk encryption, symmetric algorithms are used. Asymmetric algorithms are used for authentication and key exchange. Hashing is used as part of the authentication process.

With an SSL-based VPN, you can easily provide remote-access connectivity from almost any Internet-enabled location. All that is needed is a standard web browser and its native SSL encryption. There is no need for special-purpose client software on the remote system. This flexibility allows SSL VPNs to provide "anywhere" connectivity from corporate desktops, as well as from noncompany-managed desktops. Employees may use the SSL-based VPN to connect from home on their own PCs, contractor or business partner desktops can also be easily connected, and users can even connect via Internet kiosks. Through dynamic download, clients are supplied with all the software needed for application access across the SSL VPN connection. This feature dramatically minimizes the maintenance of desktop software.

If you need to support the remote resource needs of a diverse user base, SSL VPNs and IPsec VPNs provide complementary technologies that can be deployed together to meet these needs. Each of these VPN solutions offers access to virtually any network application or resource from a remote location. However, SSL VPNs do offer some additional features, allowing for easy connectivity from desktops outside your company's management, as well as little or no desktop software maintenance, and user-customized web portals upon login.

Establishing an SSL Tunnel

Let's examine the steps involved in establishing an SSL tunnel (see Figure 12-8):

Step 1 The user makes an outbound connection to TCP port 443.

Step 2 The router presents a digital certificate that contains a public key that is digitally signed by a trusted certificate authority (CA).

Step 3 The user's computer generates a shared-secret symmetric key that will be used by both parties.

Step 4 The router's public key is used to encrypt the shared secret and is transmitted to the router. The router's software uses the private key to decrypt the packet. When this is complete, both parties in the session know the secret key.

Step 5 The key encrypts the SSL session.

Figure 12-8 Establishing an SSL Tunnel

1. Outbound 2. Digital certificate connection to TCP with a public key port 443 is made. digitally signed by a trusted CA is presented by the router.

SSL VPN Tunnel

5. SSL Session is Encrypted by the Key

3. Shared-secret, symmetric key to be used by both parties is generated.

SSL VPN Tunnel

5. SSL Session is Encrypted by the Key

3. Shared-secret, symmetric key to be used by both parties is generated.

4. Public key of the router used to encrypt the shared secret and is transmitted to the router. The router's private key is used to decrypt the packet. Both parties now know the secret key.

Key Topic

With the SSL tunnel established, two parties may securely transmit data. By using the mechanisms discussed here, you can effectively extend the reach of your corporate network, allowing users to easily and securely gain access to corporate resources from wherever they may be.

0 0

Post a comment